7.0.1-5111 - IKEv2 not working because of 169.254.0.0
BWC
Cybersecurity Overlord ✭✭✭
Hi,
did anyone experienced IKEv2 issues, especially in Double NAT situations? I saw this a couple of times, but today a customer migrated from a TZ 500 to a TZ 570 and a former working tunnel to a TZ 270 wasnt coming up anymore.
I did some investigation and the UDP 500 from the TZ 270 arrives at X3 (behind a AVM Fritzbox), but the TZ 570 answers with Source 169.254.0.0, instead of the X3 IP. A recipe for desaster.
The quick fix was to change from IKEv2 to IKEv1 and the tunnel came up properly.
I had similar cases on Gen6 in the past, but I can't recall seeing 169.254.0.0 as Source which is utterly wrong.
The network is back in production and because it's a remote location further debugging is nearly impossible.
@fmadia @MustafaA @MasterRoshi is this a known issue?
--Michael@BWC
Answers
@BWC , I don't think this is a known issue, based on my internal search.
@BWC , what firmware is used on the Gen7 firewall? It could be related to "IKEv2 Cookie Notify" settings. If you have a chance to disable this settings and perform a test, that would be great.
@MustafaA the title of this thread gives it away :) ...its 7.0.1-5111 ... but the Cookie is something I looked already into because Wireshark showed it's Cookie related.
Hopefully the custome is able to test shortly and I'll report back. I already informed another customer with the same exact problem to give it a try.
--Michael@BWC
@BWC , the big title fonts are not big enough to catch my eyes :)
Looking forward to the test result.
Same exact issue with the current SonicOS 7.0.1-5119.
And yes, it was the "Send IKEv2 Cookie Notify" under the VPN / Advanced / IKEV2 Settings. As soon as I disabled it all tunnels came back to normal.
I have upgraded from TZ500 to TZ370, and about 40% of the tunnels did not come up. From a peer perspective it was a no response.
Packet trace showed the return UDP 500 traffic being dropped with "DROPPED, Drop Code: 736(Packet dropped - drop bounce same link pkt), Module Id: 25(network), (Ref.Id: _2186_iboemfCpvodfUsbggjd) 1:1)"
Here are the relevant trace details:
Ethernet Header
Ether Type: IP(0x800), Src=[00:06:b1:25:60:84], Dst=[00:17:c5:83:a1:59]
IP Packet Header
IP Type: UDP(0x11), Src=[169.254.0.0], Dst=[<correct peer IP>]
Please note, Src and Dst MAC addresses are bogus, i.e. not present on the network.
@BWC, thank you for posting your findings here. It really helped.
-Vladimir