Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 40 subscribers
  • Views 1744 views
  • Users 0 members are here
Options
Suggested
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

Trouble routing a packet from site A via site B to site C (with SNAT)

apijnappels

I have something strange for the following situation.

VPN connection between site A and site B (tried both policy-based and route-based) and a policy-based VPN-connection between site B and site C.

Intention is to reach site C from site A while there is no possibility to add Site A's subnet to the tunnel between B and C. Therefore from B the traffic should be SNATted to a site B ip-address.

  • Site C's subnet is in the tunnel between site A and site B.
  • Site A can succesfully reach resources at site B.
  • Subnet Site A: 10.0.0.0/24
  • Subnet Site B: 192.168.21.0/24
  • Subnet Site C: 10.23.1.0/24

At site B we did a packet capture to see what happens with the traffic and this is what happens with a ping from site A to site B, which is expected output, packet comes in gets forwarded, reply comes in and gets forwarded back to source:

However, when pinging to site C we see the packet arriving on ipsec0 just as above, then the second packet is weird; it lists traffic from ipsec0 to ipsec0 as status Generated (and not forwarded) with the source and destination address inverted and from the pinging station at site A they receive a really strange output:

  • I tried adding ipsec_route to 10.23.1.0/24 net from the console at site B
  • tried it without the ipsec_route
  • for route-based VPN I also created a SD-WAN route to 10.0.0.0/24 network to the tunnel interface
  • Route precedence is: VPN, SD-WAN, Static
  • tried to NAT traffic for 10.23.1.0/24 with firewall rule with Linked NAT rule
  • tried to NAT this subnet directly from the policy based ipsec connection

Most of the time it is just a request timeout and at some config we got the above strange output from ping.

Site A is a OPNsense firewall, site B is the Sophos XG with 19.5.3 MR-3 version on it. Site C has Cisco firewall IIRC.

I don't know what else I can try or where I am making a thinking fault. I have similar setups on other sites where traffic from A is SNATTED at B to C and they all work flawlessly, but not on this occasion.

Anyone have a clue what I'm missing and why the packet capture status says Generated instead of Forwarded?



This thread was automatically locked due to age.
  • 0

    My thought here is: Why using a Firewall in between, both could connect between each other, if that is needed. 

    And why do you have to NAT? 

    When you reach Site C, can you also show us the packet capture? And also show us the NAT rule you are using. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    I'm only managing site B. Site A is managed by customer, site C is managed by other party and is unwilling to make changes, they simply request us to just NAT the traffic. So I don't know if the traffic ever reaches C, but on other sites with similar setups this has never been a problem. There I see the Ping-traffic with status incoming, followed by status forward and the reply-traffic is also first incoming followed by a forward. In this latter case I can also clearly see the "translated IP" traveling between B and C.
    In my current issue, I don't see the translated IP but instead the original source and the destination addresses just seem to be swapped

    Managing several Sophos firewalls both at work and at some home locations, dedicated to continuously improve IT-security and feeling well helping others with their IT-security challenges.

  • 0 in reply to LuCar Toni

    Here's a packet capture from same site B and same site C. Site A is now my home firewall, this one is working as expected:

    Here you see the traffic coming in from tunnel interface (xfrm4) from 172.16.16.100 destined for 10.23.1.42. Traffic is translated to 192.168.21.3 and forwarded to ipsec0 connection to destination. 
    Ping reply comes back from ipsec0 interface to translated address and lastly gets forwarded to the original source.

    While site B and site C are the same and I believe I have the same set of rules for this site A, I don't know what I am missing here...

    Managing several Sophos firewalls both at work and at some home locations, dedicated to continuously improve IT-security and feeling well helping others with their IT-security challenges.

  • 0 in reply to apijnappels

    Can you give us an network map ? 
    And also which ipsec method you use for what. 

    __________________________________________________________________________________________________________________

  • 0

    Hi @  ,

    Let me take time to put a clear topolgy:

                                                                                             clientB

                                                                                                |

    clientA-------SiteA(OPNSense)------rbvpn tunnel-----SiteB(SFOS)----------policy base IPsec tunnel---------SiteC(Cisco)----clientC

    It is possible for clientA reaching clientC

    1) keep route based ipsec tunnel between SiteA and SiteB; on SFOS (SiteB), chose IP version: IPv4, traffic selectors: Any, Any; please check if Any/Any traffic selectors is supported in OPNSense.

    2) Assign ip address on xfrm interface on SiteB and also on SiteB's interface.

    3) In SiteA, add two static routes - one to reach clientB subnet via tunnel interface (its equivalent on OPNSense); 2nd route to reach clientC via tunnel interface.

        In SiteB, add a static route to rach clientA via xfrm interface

    4) On SiteB, create policy based Ipsec tunnel, with local subnets=clientA subnet, clientB subnet; remote subnet=clientC subnet

    5) On SiteC, create policy based Ipsec tunnel, with local subnet=clientC subnet; remote subnets=clientA subnet, clientB subnet 

    * Add firewall rules on each of the sites correctly and routing on clients appropriately. 

    * clientA can reach clientC or vice-versa.

    Let us know how it goes.

  • 0

    Thank you all for thinking with me. I just narrowed it down to the subnet of site A.

    What I did was create a new OPNsense firewall setting it up exactly as is with the customer and same LAN subnet of 10.0.0.0/24

    • Created tunnel tried to reach site C trough site B which failed the same way as with the real customer's site.
    • Changed Site A's subnet from 10.0.0.0/24 to 10.98.0.0/24 and adjusted routes on site B for the changed subnet and all worked this time!!

    I checked all my interfaces at site B, all my IP host definitions to look for double uses of 10.0.0.0/24 but could not find any. Checked all VPN site-to-site settings for other sites having 10.0.0.0 which there also were not.

    I then changed back to the original subnet 10.0.0.0/24 and again all fails.

    With the original subnet (10.0.0.0/24) I noticed in Packet capture:

    1. ping request arriving on tunnel interface
    2. next forwarded to a different address 192.168.21.254 (which is inside local LAN of site B, but it this address is not in use) I also checked all NAT rules to see if there are any DNAT (or other NAT) rules natting this source to the new destination which was also not the case. 
    3. ipsec0 interface out with source of 10.23.1.42 and dest. 10.0.0.10. This is strange since 10.23.1.0/24 is in Site C (so traffic from this source would have an in interface of ipsec0, not out interface.

    So there must be a mixup somewhere with the 10.0.0.0/24 network, but I am not able to find it.

    Anyone any clues in where to look?

    Managing several Sophos firewalls both at work and at some home locations, dedicated to continuously improve IT-security and feeling well helping others with their IT-security challenges.

Unfiltered HTML