Join the Conversation

To sign in, use your existing MySonicWall account. To create a free MySonicWall account click "Register".

7.0.1-5111 - IKEv2 not working because of 169.254.0.0

BWCBWC 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

Category: Entry Level Firewalls
Reply

Answers

  • MustafaAMustafaA SonicWall Employee
    edited April 2023

    @BWC , I don't think this is a known issue, based on my internal search.

  • MustafaAMustafaA SonicWall Employee

    @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.

  • BWCBWC Cybersecurity Overlord ✭✭✭

    @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

  • MustafaAMustafaA SonicWall Employee
    edited April 2023

    @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

Sign In or Register to comment.