Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

We presently have two sites connected via a nailed-up VPN connection. Site 1 (corporate office) has a SonicWall Pro 2040 Enhanced, and site 2 (a data center) has a SonicWall NSA 2400. The IP scheme at site 1 is 10.0.0.0/255.255.255.0, and at site 2 is 10.0.1.0/255.255.255.0.

The problem I'm having is that we have remote users that connect to site 1 via a GlobalVPN client, but because of how that VPN connection's routing is set up they can't access resources on the 10.0.1.0 network. I've tried manually adding static routes, but it appears that the SonicWall is preventing that VPN connection from making the jump to the other device.

One option is to duplicate the remote VPN users and settings at site 2, but that would require that we manually sync those users and that remote users make two separate VPN connections -- not ideal.

Do any SonicWall gurus out there know how I can configure the VPN connections to allow access to those site 2 resources?

share|improve this question

2 Answers 2

up vote 0 down vote accepted

I don't know about the Pro's, but when connecting to an NSA with the the Global VPN client, you have to specify which networks that user has access to (either individually or by the groups they belong to). For instance, I created an address group object (REMOTE_USER_ACCESS) containing all of the networks I want my VPN users to be able to access (Our setup is the exact same as yours.. an office and data center with a site-to-site VPN tunnel done by an NSA3500 on each side.. user's connect to VPN on site A but access resources from private network at site B). Then, I either go to the individual user's account (Users > Local Users) or the group (Users > Local Groups), edit the user, click on the VPN Access tab and add the REMOTE_USER_ACCESS object. The VPN user can now access any networks I've specified in that address object.

Like I said, that's for the NSA, but I'm guessing the Pro isn't going to be too much different.

share|improve this answer
    
I'll give that a try and report back –  Josh Mar 11 '12 at 23:06

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

Consider 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. Servers behind firewall A see originating connections from X as their remote IP address.

In this scenario, the packet from X gets tunneled to A, which then VPNs it to B, which forwards it to S. In order to close the loop and send information back, S needs to send a packet back to X. To the packet goes to B. 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. This packet will probably get NAT'd to some address of B's and sent direct across the internet. 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. The loop never gets closed.

I saw this years ago with the 3Com SuperStack-3 firewalls, which I understand were related to the Sonicwalls of the day. We encountered this problem with a site that had two SS3s VPN'd together.

We never solved it with that hardware.

VPN solutions we use now assign local IPs to the VPN clients, so as far as the internal network is concerned, the VPN clients are connected internally. This means that in the example case firewall B sees X as originating through the VPN with fireall A, and routing works.

share|improve this answer
    
We actually use the DHCP server at site 1 to assign internal IPs to VPN clients. Those IPs are in the 10.0.0.x range, so I believe the requests to the servers at site 2 should see that IP. I'll check the VPN logs and see if I can't get some detailed info to determine if the NAT issue is what's happening. –  Josh Mar 9 '12 at 5:45
    
You might also snoop traffic at a target at site 2 to ensure that the traffic is even getting there. Also it occurs to me you might check your (client) VPN configuration to ensure that traffic bound for site 2 would even be tunnelled -- either explicitly through a rule (sometimes called split-tunnelling), or implicitly by capturing all outbound traffic from the client via the VPN. –  David Mackintosh Mar 9 '12 at 5:49

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.