This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Policy Based routing through IPSEC VPN

Hi All- 

Please forgive me for reposting this, however the previous post I had replied to with this (https://community.sophos.com/utm-firewall/f/network-protection-firewall-nat-qos-ips/114954/routing-single-local-host-internet-traffic-through-remote-ipsec-tunnel-gateway) has been locked due to inactivity and I am again revisiting trying to make this work. 

and - you were the experts in that thread, perhaps you can shed some light on my situation. 

SITE A: is a branch office with 192.168.68.0/23 and 10.0.1.0/24. SITE B is HQ. SITE B has 192.168.64.0/22

All traffic from SITE A that originates from an IP in 10.0.1.0/24 should traverse the IPSEC tunnel and egress via the SITE B firewall WAN interface. 

Here is the tunnel status, as you can see, it has established correctly: 

Using either a masquerading or SNAT rule, I can get traffic to exit via the WAN interface at SITE A, but remember, we want this to go back to SITE B first via the tunnel. Per the above thread, I created a PBR on SITE A (BRANCH OFFICE) firewall. NOTE: "Remote_LAN is the internal local IP on the HQ (SITEB) firewall, 192.168.64.1.

This immediately breaks the internet at SITE A. I can still be on a workstation at 10.0.1.2 and ping 192.168.64.1, but once the above PBR is enabled, internet breaks. No logs are found at the HQ site that originate from the tunnel. 

both sites have been tested with an ANY>ANY firewall rule, along with "auto firewall rules" on both sides for the IPSEC tunnel, which makes no difference. 

I've also tested iterations of disabling the SNAT rule (and/or masq rule) at the BRANCH site, makes no difference. As soon as the PBR is enabled, internet breaks. 



This thread was automatically locked due to age.
Parents
  • 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. 

Reply
  • 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. 

Children
  • 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 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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA