Force traffic over SonicWall VPN

MISquared
MISquared used Ask the Experts™
on
We have two sites connected via a VPN between two firewalls. The remote site uses a LAN ip scheme of 89.0.0.0/24. The local LAN uses 192.168.1.0/24 and has a SonicWall TZ 205. The VPN is up and running, and a tech at the remote site can use RDP over the VPN to control one of our local workstations; however, software installed on the local workstation, which needs to communicate with a server on the remote site does not have its traffic routed correctly. When we ping or trace traffic to 89.0.0.57, for example, it goes to a host in Germany instead of over the VPN.

I thought that, with the VPN setup, all traffic going to 89.0.0.x would default to going over the VPN. Anyone know what I'm missing. I don't want all of our internet traffic going over the VPN, just traffic to 89.0.0.x.

Thanks!
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Gilbert HauserConsultant informatique

Commented:
Hi,
Your remote site is using a public range of ip address provided by your ISP or this is an unfortunate coincidence that they used these address ?

Author

Commented:
An unfortunate coincidence. I guess they didn't understand the implications when setting it up. The tech in the other location acknowledged the mistake but indicated that it could not be changed. I might push that issue more if I can't work around it.
Greg HejlPrincipal Consultant

Commented:
The internets is going to use every chance that it can to route that traffic to germany.  

The guy in germany is not gonna be happy about that either.

If he's running dhcp it should be pretty easy to change the ip schema.  change a couple of switches and other manual ip's and chalk it up to lessons learned.
Ensure you’re charging the right price for your IT

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

Commented:
Hi MISquared,

Although it is quite unfortunate that the remote site uses the 89.0.0.0/24 network for their LAN, if the VPN policy is configured correctly, this won't matter one bit.

Let's start with some basics:

1. What terminates the VPN at either end? We know that one site is using a SonicWALL, what's at the other end?
2. What is the model of the VPN terminator at each end (e.g. NSA 3600)?
3. Which version of firmware is running on each (e.g. SonicOS 6.2.2.2-2o)?
4. Attach a screenshot of the VPN configuration at each site. Take care to exclude public IPs and passphrases.

Thanks!

Author

Commented:
I'm not sure what's at the other end. I requested that info. I do have a screenshot that they provided. It's attached.

Locally there is a SonicWall TZ 205 running 5.8.1.13-2o. A bit out of date. The local VPN config is attached as well.
LocalVPNConfig.docx
RemoteVPNConfig.docx
Gilbert HauserConsultant informatique

Commented:
do you have a policy route from Local LAN to 89.0.0.0/24 with your VPN as Next hop?

Author

Commented:
No. I haven't had to do that for any other VPN setup like this. Is that standard procedure?
Gilbert HauserConsultant informatique

Commented:
It is not a standard, you are right, but may be a way to force the trafic to the vpn instead of the default gateway to internet. Normaly they are no reason to route a trafic to public Ip thrue your VPN.

Author

Commented:
If you can link to documentation on how to do this on the TZ 205, i'd appreciate it.

Commented:
In SonicOS, for a traditional policy based VPN, you cannot create a static route to route traffic through the VPN tunnel. This is not a concept in SonicOS and attempting to do so will make the problem worse.

Author

Commented:
Hi Tyrant, have you seen anything in the screenshots that I posted that appears to be incorrect? The model of the firewall on the other end is fortinet FG90D. I was reading something about creating a tunnel interface VPN (route-baed VPN) as seen here: https://support.software.dell.com/kb/sw7902. Is that something to look into you think, or is that going in the wrong direction?

Commented:
Hi MISquared,

Be sure that the local and remote networks specified in the configuration at both ends match the network segments exactly. On the SonicWALL side, I see that you're using Firewalled Subnets for the local network designation which is a lose definition for ALL subnets that the SonicWALL is a member of. If there are multiple local networks that must participate in the VPN, create an Address Object for each, then add them to an Address Group called something similar to "VPN xyz Local Networks". Do the same for the remote networks.

Work with the tech at the other end to set the respective local and remote networks to the exact same values.

You may also need to enable "Enable Windows Networking (NetBIOS) Broadcast".

I see no other issues in the SonicWALL's configuration.

I hope this helps.

Commented:
Hi MISquared,

Tunnel Interface VPN is a good option for a number of scenarios, but I don't believe that you need to go in that direction as it's a bit more work to setup and troubleshoot if something goes wrong, and the cross-platform support is sometimes a hit-or-miss.

If you do go this direction, I HIGHLY recommend upgrading to the latest version of SonicOS 5.9 first.

Author

Commented:
Hi Tyrant,

Regarding the network segments matching exactly...locally, this has been verified, I'm awaiting for confirmation from the remote site. There is only one network behind the local firewall; nevertheless I created an address object for the LAN and specified that in the VPN configuration. I also enabled the NetBIOS broadcast.

Despite all this, traffic to the IP address of the remote site still goes out to the internet rather than across the VPN.

Author

Commented:
I think, after looking more, that the tech at the remote site is sending me on a wild goose chase because things aren't working the way he "thinks" they should. After running some diagnostics, I think that the traffic to 89.0.0.57 is in fact going over the VPN and not out to the internet. I think my best course of action is to get more information about what he is trying to do over the VPN and assist him with getting it done rather than troubleshooting a problem that does not exist. Thank you all for your advice, but I think this is a closed case.

Commented:
Hi MISquared,

I just wanted to follow up to see how you fared with this.
It turns out that the tech at the remote site had something misconfigured on his end but came to the incorrect conclusion that traffic was not going over the VPN from here to there when in fact it was working fine. Thanks for your comments and ideas.
Blue Street TechLast Knight
Distinguished Expert 2018

Commented:
Glad it was taken care of. Please select Best Solution for your own comment if that ended up being the solution to close this question.

Thanks!

Author

Commented:
Red herring

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial