We encountered this problem with a site that had two SS3s VPN'd together. I saw this years ago with the 3Com SuperStack-3 firewalls, which I understand were related to the Sonicwalls of the day. So when the packet gets to X, it has IP addresses on it (and possibly ports) which don't relate to any conversation that X thinks it is actually trying to have, so X (should) discard it. This packet will probably get NAT'd to some address of B's and sent direct across the internet.

Here's where the problem happens: B's route to X is direct across the internet - not across the VPN, which is where it actually came from. In order to close the loop and send information back, S needs to send a packet back to X. In this scenario, the packet from X gets tunneled to A, which then VPNs it to B, which forwards it to S. Servers behind firewall A see originating connections from X as their remote IP address. But if you route the packet across a VPN, you will almost certainly find return packets come back through a different NAT station than you intend.Ĭonsider remote user X accessing firewall A which has a VPN to firewall B, behind which is server S that you want user X to access.

Which isn't a problem as long as firewall A is the gateway back to the internet for all the intended internal targets. With some VPN clients, the firewall identifies user X as being from their 'real' IP address. It has to do with how the firewall identifies the remote VPN user's IP address internally.

Global vpn setup