Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 27 subscribers
  • Views 2183 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

IPsec tunnel issue with multiple active WAN interfaces

Markus Rüping

Hello everyone,

at the moment I'm looking into a very strange issue regarding an IPsec Setup on my XG with multiple WAN Interfaces.

First of all, to give you an overview, therelevant interfaces:

  • PortA - internal LAN with 192.168.13.0/24 directly attached
  • PortD - PPPoE Uplink, marked as backup connection in WAN link manager
  • PortE - leased line with an /29 on it, so there are the Ports E:0 to E:4 for all available IP adresses from this subnet; active connection in WAN link manager with a weight of 60
  • PortG - LTE Router, the XG is DHCP Client; active connection in WAN link manager with a weight of 40

On the XG Box there are 6 IPsec connections. Each one with local / listening interface PortE:0.
IPsec types are mixed IKEv1 and IKEv2, sometimes have multiple Subnets, somtimes only 1on1.


Issue description:

All IPsec connections initiate flawlessly, however some of them don't pass traffic over to the remote networks if initiated on the XG side.
This is no stable condition; sometimes it works, sometimes not. Even the sessions that work change from time to time.

 

First investigations:

Utilizing the Packet Capture feature in XG it comes clear, that the traffic is always correctly routed to the ipsec tunnel and seems to leave the XG on the tunnel interface ipsec0.
Looking further via tcpdump on advanced shell via tcpdump dst <destination gateway address> it comes clear, that there is a substantial routing issue with the IPsec traffic:

While the IPsec session traffic (aka isakmp) is leaving on the correct wan interface (PortE), the ESP traffic leaves on PortG!

PortG is not associated to the IPsec connection anyways. And needless to say, that with traffic originating from a completely different IP the other side has no chance then just dropping it.
It looks like PortG is choosen sometimes based on the WAN link weight - this made the issue hard to track down for me and should be the reason why it isn't encountered all the time.
Maybe this occurs only on alias interfaces, but unfortunately I'm not able to test this in my scenario.

So there are some questions now for me:

  • has anyone experienced this issue so far?
  • is there any chance of a wrong configuration leading to this issue?

For the records: I raised a case with sophos (#9895016) but awaiting response.

 

Regards,

Markus

 



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

    Hi  

    Thanks for descriptive information and clear explanation.

    Here based on information provided the IPSec tunnel are configured on PortE:0 which is alias Interface.

    If you have configured IPSEC over Alias and if you are having Multiple gateway configured  on XG then we need to enable below command in order to enable routing on Alias Interface.

    console> set routing source-base-route-for-alias enable

    So enabling this command will fix the problem which you are facing with incorrect Interface traffic passing or communication not working. 

    As per your update you have already tried for the same then you may confirm the ESP packet to check and conclude the issue further.

  • 0 in reply to Vishal_R

    Hello Vishal,

    thanks for your fast reply.

    Unfortunately - as stated above - this does NOT fix my issue.
    Maybe I'm missing further configuration steps?

    Best,

    Markus

Reply Children
  • 0 in reply to Markus Rüping

    Hi  

    Further you may capture the ESPDUMP or ESP packet (protocol 50) on XG shell or CLI via below command:

    Command from shell:

    #tcpdump -ni any proto 50

    Command from console CLI:
    console> tcpdump 'proto 50 

    If you are running multiple tunnels and you would like to capture the traffic for interested tunnel over which you are facing an issue in such case you may collect the tcpdump on XG over that IP directly via below command.

    Command from shell:
    # tcpdump -ni any host X.X.X.X

    Command from console:
    console> tcpdump 'host X.X.X.X

    Reference Output:

    console> tcpdump 'proto 50
    tcpdump: Starting Packet Dump
    12:40:33.719009 Port2, OUT: IP 10.201.208.90 > 10.201.208.74: ESP(spi=0xce7e0b05,seq=0x14), length 104
    12:40:33.720733 Port2, IN: IP 10.201.208.74 > 10.201.208.90: ESP(spi=0xc15b8ebc,seq=0x14), length 104
    12:40:34.741282 Port2, OUT: IP 10.201.208.90 > 10.201.208.74: ESP(spi=0xce7e0b05,seq=0x15), length 104
    12:40:34.742419 Port2, IN: IP 10.201.208.74 > 10.201.208.90: ESP(spi=0xc15b8ebc,seq=0x15), length 104

    You should be able to see correct interface for in and out packet first and if that is fine then reply packet should come from remote end gateway for the out sequence number.

  • 0 in reply to Vishal_R

    Hello Vishal,

    i don't see how this could help.
    I'm not having issues to track down that the wrong interfaces are used at the moment.

    Further after changing the setting mentioned in the KBA nothin in the tcpdump changed.
    And in fact there are no packets incoming as there is nothing on the other side that can answer - simply, because it isn't receiving any requests.

  • 0 in reply to Markus Rüping

    Hi  

    If still its taking another Interface then issue could be at routing side(settings) on XG with different reason and possibilities which could be due to static route , PBR or BGP running on PortG having default route learned etc or some misbehave at routing end. This can be investigated with support case further and you have already raised the same.