Policy Based routing through IPSEC VPN

Hello Aaron,

if network 192.168.68.0 /24 does not have to go through the tunnel, why do you define an SA for this?

It is a subnet which requires access to HQ resources but need not egress to internet via HQ. Removing it as a testing measure does not yield different results. 

I've unlocked the original thread, but let's continue here.

I don't think Policy Routes work with a tunnel that's not bound to an interface, even then, I don't like that solution.

Please show pictures of the Edits of the IPsec Connection and Remote Gateway with 'Advanced' open from both UTMs.  Also a picture of the Edit of the SNAT that's not working.

Cheers - Bob

Leaving this here in case anyone stumbles upon this via search down the road:

So I've been doing some extensive testing on this in a lab environment. I can get this working in a virtualized lab (as another user did in the above linked thread). However, a trial run in real life yields very different results. Each time, whenever enabling either a policy route (or a standard static route) - the internet connection become unstable and flags to "Error" in the dashboard. Ping tests outbound from any device on the network shows intermittent drop outs. 

I then suspected this might have something to do with the clients I was trying to statically route to another site for internet egress getting stuck in some kind of OSPF routing loop - so I tested from a network which was not involved in any OSPF routers. Same result, internet breaks for the entire site. My next step will probably be to rent some cloud server space and attempting to test this in a completely fresh isolated real environment, since my virtual lab suffers the same problem as the previous linked thread did, with everything eventually egressing out to the same WAN. The idea here is to figure out which part of a more advanced configuration is causing the internet to break when a static route is enabled.

Just leaving this here in case someone ever stumbles upon this. As of today - I've come to the conclusion the Sophos UTM does not support the configuration I want to do. While in the previous linked thread and through my lab test, I do concur, this is very possible in a lab environment where the WAN ips are actually on the same subnet. I don't know why it makes a difference, but it does. Identical configs but when the tunnel is moved from a local tunnel to over an actual WAN/internet - it does not work. 

I know the residents here will want the screenshots... I'll get them posted when I'm... less frustrated. More posting this as an FYI for anyone down the road so they don't spend hours beating their head on the wall like I did. 

Cheers!

Main "HQ" side: 

for reference, the remote networks are: 192.168.190.1/32, 192.168.190.128/25. I know, they're weird networks, but it's irrelevant. 

RULES:

a trusty any-any-any rule. ICMP is allowed straightaway via the ICMP tab. 

And the NAT: 

Remember, that's all for the site where we want traffic to EGRESS. 

------

BRANCH side: 

Note: both of those internal networks match the remotes defined at the opposite site. See the successful IPsec tunnel below... 
another trusty any-any-any, ICMP is enabled straightaway via the ICMP tab. 

Here's the resulting tunnel: 

Here's the PBR rule: 

Result (does not work):

Logs on the HQ side are empty, minus the usual random inbound junk getting blocked from who knows where in the world. :) 

Sorry to disappoint folks, but it just doesn't work. The Branch FW drops the traffic and it never traverses or arrives at the HQ side. See my next post where I'll change the tunnel to be two local WAN and magically it works. I suspect it's something with the NAT rule on the branch side - because I don't know why I'd nat out to the WAN IP of the branch when that's... not what I want. 

BUT, I tested that. Tried nat'ing to a different internal IP (one known by the tunnel SAs). Same result. 

Here's the test with both WAN interfaces on the same "WAN" subnet (though in this case, they're both actual internet IPs, but they live within the same virtualized instance, so maybe that's the issue? Either way, I'm not renting another cloud server to test, because I don't believe it's going to make a difference. 

Established Tunnel: (no masking of IPs, they aren't mine and I'm dumping them next week, port scan them away, hackers!)

SIDE B: 

it works! (in a lab only) 

note that the traverse here is 192.168.190.129 (branch FW LAN) > tunnel > 23.229.5.21 (public IP of HQ) 

Here's without the PBR turned off:

note it's going out the WAN IP of the HQ firewall 

I think that screenshot tells the story best. You can follow the routing here via the LAN of the first sophos - through the tunnel (allegedly) and out the other FW. Notice the web IP of the firewall I have pulled up and the traceroute of the local machine. 

Sadly, unless BAlfson or the other residents have anything to add, I think this is the nail in the coffin, this simply doesn't work. :) 

I think I said in my first post in this thread that Static Routes don't work with IPsec tunnels unless the IPsec Connection is bound to the WAN interface.

It's easiest and clearer to add things to the tunnel.  Say the goal for 192.168.190.128/25 in site A is to have its Internet traffic exit the WAN connection in site B.  In Site A, 'Local Networks' = 192.168.190.128/25 and 'Remote Networks' = "Site B LAN" & "Internet IPv4."  In site B, 'Local Networks' = "Internal (Network)" & "Internet IPv4" and Remote Networks' = 192.168.190.128/25.  The routing will be done automagically. You will need a firewall rule and/or adding 192.168.190.128/25 to web filtering in site B.

Instead of "Internet IPv4," I've used this latter approach more often to have traffic from branch offices to specific sites reach the sites via an IPsec tunnel to the home office.  This allows the branches to reach sites that limit access to only certain IPs.

Is that what you wanted to accomplish, Aaron?

Cheers - Bob