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 1743 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.
Parents
  • 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.

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

Children
No Data
Unfiltered HTML