Guest User!

You are not Sophos Staff.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 26 subscribers
  • Views 915 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

Policy Based IPSec VPN not routing through tunnel

OlvrKl

Hello everyone,

I created Site to Site IPSec VPN Connections before for a customer, which worked just fine. Strangely I encountered the following Problem with the latest connection and I couldn't find any problems regarding the configuration. Maybe you can help me in this case.

I do not have control over the remote appliance.

We have three local subnets and one remote network, which is basically just one IP, but configured as a /32 network.

We configured the IPSec VPN on both sides and exchanged PSKs and the tunnel was immediately connected and the three SAs were established.

IPSec-Policy:

IKEv2 Mainmode
Phase1:
DH-Group14
AES256/SHA256
Phase2:
DH-Group14
AES256/SHA256
DPD deactivated

IPSec-Connection in the XG:

Site2Site
initiate connection
Authentication: PSK
local/remote ID Type: IP-Address with the local and remote gateway.
No NAT on both sides

Routes are set to the virtual ipsec adapter correctly according to advanced shell, when IPSec-Connection is enabled. But I can't ping the remote subnet/IP-Address.

When I try a traceroute either from the XG Webadmin or one of the local subnets while connected, the first hop is beeing routed to the remote Gateway-Address (the remote external Interface, that is beeing used to establish the tunnel), which I just can't get my head around. I can't get the connection to work properly.

I'd appreciate any help!

Thanks in advance,

Kind Regards,

Oliver



This thread was automatically locked due to age.
Parents
  • FormerMember
    0 FormerMember

    Hi ,

    Ensure that you have set up LAN to VPN firewall rule.

    Is there any static route or sd-wan policy configured for the remote networks?

    Please take a packet capture while initiating a traffic from any of the local subnets and share capture output snapshot.

    ==> Go to Diagnostics > Packet capture

    Enter BPF string: host <remote_network_IP> and proto ICMP

    eg: host 192.168.10.20 and proto ICMP

    ==> Try to ping/tracert to remote_network_IP from local subnet machie.

  • 0 in reply to FormerMember

    Hi Yash,

    thanks for the fast reply. 

    I created Specific Rules VPN/Subnet <- Any -> LAN/Subnets.

    We don't use any sd-wan policies or static routes. The remote network in this VPN Connection ist 172.16.101.165/32

    I took a packet capture with the following BPF string: host 172.16.101.165 and proto ICMP

    The Pakets are only onesided. No packets are beeing returned from the remote host.

    One thing I have encountered while testing, is that anohter firewall rule was used in the Log-Viewer during tests. A firewall rule from another S2S IPsec VPN. The other VPN has the remote subnet 172.16.64.0/18, which includes 172.16.101.165. Strangely after deactivating the other VPN Connection temporarily the results seem to be the same.

    I'm still confused why the external IP from the problematic VPN Connection is used as the first hop and not the direct connection through the tunnel. Do you need more information from the details pane of the packet capture?

    Kind regards,

    Oliver

  • FormerMember
    0 FormerMember in reply to OlvrKl

    You need a source NAT policy to route firewall initiated traffic over an IPSec VPN tunnel.

    OlvrKl said:

    The Pakets are only onesided. No packets are beeing returned from the remote host.

    As per the packet capture request to 172.16.101.165 is being forwarded over IPsec tunnel(ipsec0), but there’s no reply packet coming back.

    OlvrKl said:
    The other VPN has the remote subnet 172.16.64.0/18, which includes 172.16.101.165. Strangely after deactivating the other VPN Connection temporarily the results seem to be the same.

    After disabling/deactivating the existing tunnel configured with 172.16.64.0/18 subnet, please flush the connection for 172.16.101.165 and then try to access it.

    ==> Login to SSH > 5. Device Management > 3. Advanced SHell

    # conntrack -D -d 172.16.101.xx

    Could you also please check whether the request packet is hitting the remote end firewall/router or not?

  • 0 in reply to FormerMember

    Hello Yash,

    I will get in touch with the Admin of the Remote Site, so we can troubleshoot better. I'll update as soon as we have results.

    Regarding your NAT-Suggestion, so that I can understand what you mean:

    I need to create an ipsec-route likes this:

    system ipsec_route add host 172.16.101.165 tunnelname [TunnelName]

    Do I need a dedicated IP-Adress for the snatip? It would look something like this:

    set advanced-firewall sys-traffic-nat add destination 172.16.101.165  snatip <NATed IP>

    Then Add Public IPs from each side to the corresponding local and remote subnets. Does the remote Site need to add any configuration for this?

    What we basically do here is creating a rule for this one IP-Address, that has higher precedence then the existing subnet 172.16.64.0/18 and its rules and solves conflicts.

    Thanks a lot and kind regards

    Oliver

Reply
  • 0 in reply to FormerMember

    Hello Yash,

    I will get in touch with the Admin of the Remote Site, so we can troubleshoot better. I'll update as soon as we have results.

    Regarding your NAT-Suggestion, so that I can understand what you mean:

    I need to create an ipsec-route likes this:

    system ipsec_route add host 172.16.101.165 tunnelname [TunnelName]

    Do I need a dedicated IP-Adress for the snatip? It would look something like this:

    set advanced-firewall sys-traffic-nat add destination 172.16.101.165  snatip <NATed IP>

    Then Add Public IPs from each side to the corresponding local and remote subnets. Does the remote Site need to add any configuration for this?

    What we basically do here is creating a rule for this one IP-Address, that has higher precedence then the existing subnet 172.16.64.0/18 and its rules and solves conflicts.

    Thanks a lot and kind regards

    Oliver

Children
No Data