Today I experienced an issue with our XG firewall and an IPSEC tunnel we have with a client.
Due to requirements on their side, the public IP for their endpoint (say 1.2.3.4) is the same as the internal IP address they are natting their traversing traffic behind. So the public IP of their endpoint is 1.2.3.4 and the traffic sent across is also natted as 1.2.3.4
This has been working fine for about 2 months. The tunnel is only needed sporadically and their side only initiates it when traffic needs to be sent.
Yesterday everything was working fine for a couple hours, but today the tunnel refused to initiate and all I saw on my side was timeout errors.
After reviewing the edge firewall (the XG is inside it), I didn't see the XG sending any traffic on port 500 or 4500 to their side. ICMP traffic was working fine, but not 500 or 4500.
When I did a capture on my side I saw the traffic going "out" but it said the out interface was "ipsec0" nothing was being sent out the actual WAN interface. This is despite the fact that the tunnel was down and thus there was no valid ipsec interface for that traffic to go out (and also the traffic was tunnel initiation traffic not actual traversal traffic.
I attempted to fully re-initialize the IPSEC tunnel configuration and deleted the old one, bu that did not resolve the issue. Finally I did a reboot of the XG corrected the issue and everything is being sent as normal now.
Unfortunately I was in a bit of troubleshooting emergency mode so I didn't save the trace to provide here. If there's any other logs that might be saved through a reboot, I'd be happy to provide them.
Are there any known issues with having the remote subnet/encrypted domain equal to the public IP address of the remote endpoint such that the traffic is not actually sent out over the WAN interface? Has anyone else experienced issues with traffic seeming to be routed over a "ghost" ipsec0 interface when the tunnel isn't up?
This thread was automatically locked due to age.
