I have this setup:
Click for picture
What I’d like to do is route just client 3’s traffic at site 2, through the VPN tunnel and out to the internet via site 1. I thought it would be fairly simple,
At Site 2:
Create address object for client 3
Create route from client 3 to ANY, any service, using gateway of site 1 tz600 internal ip
At site 1:
Create address object to client 3 site 2 IP
create reverse route of from any, to client 3 site 2 ip using TZ600@site 2 internal ip
The site to site tunnel has been there for years. all clients from each side can see the other sites internal ips. So that all works.
. When I create the above rules, the client 3’s tracert just times out when trying to reach any general internet ip (like 8.8.8.8), can’t go anywhere except the internal lan IP’s from either site. Packet montior from site 2 shows “received” but nothing blocked or discarded or dropped. Site 1’s packet monitor shows nothing when I set the filter for show any traffic to 8.8.8.8 (or I tried filter from client 3 site 2 ip) . Like the traffic never reaches site 1’s router. Nothing blocked, dropped, recieved consumed, nothing. Since nothing is dropped or blocked, there are no rules I can make. So how can I route client 3@site 2 traffic to the WAN via site 1 through the VPN tunnel? Any ideas?
Just make a new tunnel interface and add a route sending everything from this user over the tunnel. - or find out what internet resource actually requires only this one use to exit via the other side of the VPN, and wrap only that host in your working site to site vpn tunnel.
Can I ask you why you want to do this?
If you have a link over the internet through an IPSec tunnel, what benefit are you getting from leaving site 1 to get out to the internet? Why not just have local breakout?
create reverse route of from any, to client 3 site 2 ip using TZ600@site 2 internal ip
If you are using an IPSEC tunnel, the route to client3 at Site1 is not needed. The SA will effectively route traffic to your Site2 subnet from site1’s. Might even cause issues.
So that request for 8.8.8.8 will never go anywhere, because the gateway you specified is on the other side of a tunnel that only ships traffic to/from site1’s subnet to site2’s subnet. And 8.8.8.8 is not in either of them I bet. Setting a route does not change the VPN policy.
If you add an open ended policy for site1’s side of the tunnel, you might be able to force just a single IP’s traffic through it with routes, but it might also route all of site2’s subnet requests to site1’s subnet gateway. Depends on internal routing tables you can’t control.
My suggestion, put client3 in a different subnet. And add a new policy to your existing IPSEC tunnel that routes/allows all traffic from this new subnet/client to site1’s gateway.
OR
Install a SSLVPN client on client3, and do a full tunnel into site1’s TZ.
I thought about that, when I tried to do that it says “Found a policy with the same peer gateway. Shared tunnel interface policy is not allowed.”. Can’t have two tunnels to the same peer.
There’s a service we use and the deal was by number of servers we connect to it. We moved one of our servers to the site 2, and now they want to charge by incoming site & # servers. Like a multiplier. This isn’t a TOS where they can change them at any time. There’s a signed contract and they’re system is auto billing us with the multiplier. Very similar to what netflix does when using your acct from another IP like a vacation house, they want you to sign up for a new acct. So by routing that macihnes WAN traffic, or traffic to a handful of IPs of the service, then it appears it’s still coming from the original site IP. I’m just trying to avoid a long drawn out conversation with them.
Yes, this is the key, I didn’t understand the network policy page on the VPN network tab is the definer I thought it was just auto making some routes and rules you could add to.
So thats my issue.
But I would have though the packet monitor would show something like yeah, we’re throwing these out. I can’t do a SSLVPN client for two reasons, the heavy traffic is coming from the other users aat the site which is why its there, and the client is an AIX machine for which there is no SSLVPN client.
wait - so you already have tunnel interfaces configured? i see you mention “routes” above…
If you have a site to site tunnel - you cant add a route over it.
If you have a tunnel interface. then possibly your route at site 2 is incorrect.
But wouldn’t this be spotted by the source/destination port being different but having the same IP? Not sure what you mean here tbh
The tunnel between the two sites is site to site. I can’t add a tunnel interface with the same peer as the site to site. Can I change the site to site to a tunnel interface and make my routes for the internal subnets manually then so those still work then add my route for client 3@site2 traffic to the site 1 gateway?
yeah, that is probably the best path forward.
for a site to site tunnel - you cannot add custom routes on the routing page. you must use the network tab inside the vpn policy, and both sides must match.
but, messing with that is going to effect everyone, so you are better of converting to tunnel interface so you have more granular control over the routing.
Well, if I add the IP I want into the address object that goes into the VPN network page on the site to site, it works!
But it won’t do address objects groups that contain a FQDN, which I kinda have to use because the thing we need to get to has multiple round robin IPs and they change over time. So, yeah, probably need to convert to a tunnel interface and add all the internal subnet routes, plus the new one I want. Thanks for the insight!
tunnel interfaces are bound to an interface - if you have multiple WAN in failover, you will need to build a tunnel interface for each one - check the advanced tab for the interface binding.
when you build the second one, the SonicWALL with throw an unusual message about overlap… ignore it, assuming you are certain you have your interface binding accurate.
When you build your routes, use the multiple-path options.
After everyone left I brought the tunnel down and switched it to Tunnel interface, added the internal subnet routes manually so all the machines from site 2 can access machines at site 1 and opposite, then added what I wanted the one machine’s traffic over the VPN then out, and bingo, all working perfectly!
I only have one small residual problem, I cannot manage the sonicwalls from the other side on the internal address. The boxes are checked in the VPN policy to allow SA mgmt and user login. I see in packet monitor it says DROPPED, Drop Code 726(Packet dropped - Policy drop), Module Id: 27(policy), (Ref.Id: _2251_rqnke(Ejgem) 3:1). I cannot find any access rule with deny that has any hits. It’s reaching the other side, it’s the receiving sonicwall saying not allowed and dropping, so it’s not a route.
I figured it out. I just needed to add an access rule for https mgmt and the key is to also tick the “enable management” checkbox. I didn’t see that one. I added the rule before but without the enable mgmt checked, you can get to the mgmt page. I would think ticking the boxes in the VPN page for SA mgmt would make those rules for you? Oh well. it’s all working now. Thanks for the help, the tunnel interface was the way to go, and yeah, far more granular routing opportunities now.
great news! Glad its working for you.
Yeah, there are occasional quirks to work out like that - the great news is you had the ability and skills to work through it - so that is even better!
