Join the Conversation

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

NSA 2600 - Route Disabled After Reboot

RyanHRyanH Newbie ✭
edited January 2021 in Mid Range Firewalls

Hi all,


I have been having an issue lately with multiple NSA 2600 firewalls on the latest firmware.

Both affected appliances, at different customers, have tunnel interface VPN policies. At one of the sites, the tunnel interface VPN connects two SonicWALLs together. At the other site, the VPN is connected to an Azure VPN gateway.

When either of the affected appliances is rebooted or suffers power loss, the route policy pointed to the tunnel interface remains in a disabled state and traffic won't flow across the VPN. Once I renegotiate the VPN manually, the route becomes enabled and everything works fine. This is requiring manual effort every time an appliance reboots, which is really sub-optimal. I even rebuilt one of the appliances from scratch and it did not solve the problem. The state of the setting "“Disable route when the interface is disconnected” on the route policy does not have any impact on the behavior.

None of our 6.5 products (NSA 2650, for example) or lower end Gen6 products (TZ500) are facing this problem. In our environment, only the NSA 2600s seem to be affected.

Has anyone else seen this?

Category: Mid Range Firewalls
Reply
Tagged:

Comments

  • RedNetRedNet Enthusiast ✭✭
    edited October 2020

    We see the same ourselves since upgrading NSA 2600 to 6.5.4.7-83.

    Post reboot after applying the update all route based vpn's are established but the route is greyed out/unactive in the routing table.

    Bounce the VPN and the route becomes active in the routing table again.

    The route is not reliant on or associated with any probes.

    Gen 6.5 TZ4/5/600 and NSA2650 and 4650 are fine.

  • Hi @RYANH,

    Sorry to know that the issue has been in place for quite sometime now and also regret to hear that your support experience was not up to the mark.

    Couple of questions from me to understand the issue better. PFB the questions.

    • What is the state of the VPN tunnel (UP or DOWN) when the route gets disabled?
    • Do you know the firmware versions that you have been facing this issue?
    • Do you have any probes set on the route policy if there are multiple VPN policies to same peer location?
    • Please share the past support case no's if any in which this same issue was reported.

    @RedNet - You too can provide answers to above questions if possible.

    Will get back to you with after checking. Have a good one.

    Regards

    Saravanan V

    Technical Support Advisor - Premier Services

    Professional Services

  • RyanHRyanH Newbie ✭

    Hi @SARAVANAN,

    State of the tunnel is always up.

    Issue seen at least in the following firmware versions:

    6.5.4.7-83n

    6.5.4.6-79n

    No probes.

    Reported by a colleague in case 43536841. They told us to make sure keepalive was only enabled on one end of the tunnel. Tried that but it did not change the behavior.

  • Hey @RYANH,

    Thanks for the details.

    I verified the support case and it seems to be in pending closed status. The issue definitely needs someone to take a look at the logs and captures possibly to identify the root cause. I would suggest you to reopen the support case by sending a web update or email or phone call and resume further with the case for a fix.

    Have a good one!!! 

    Regards

    Saravanan V

    Technical Support Advisor - Premier Services

    Professional Services

  • I've had the same issue with TZ400's and a NSA3600 and I believe a NSA4600. I'm about to convert my tunnels back to route based rather than an interface because of this. I hope they fix this bug.

  • @CB3INSTATIC - Please have this issue reported if not done already.

    Regards

    Saravanan V

    Technical Support Advisor - Premier Services

    Professional Services

  • RedNetRedNet Enthusiast ✭✭

    Hi, the issue is not config based, it is a firmware bug. The tunnel route does not become active automatically when the FW is rebooted, only on the latest firmware and on Gen6 devices.

    After reboot the vpn tunnel is up (route based VPN), but needs to be disabled/enabled for the associated routes in the routing table to be active (not greyed out).

    The routes will auto disable if the tunnel interface goes down, so I assume on reboot this check is happening before the tunnel establishes or not at all.

    Again, only on Gen6 after updating to latest firmware and not on any Gen 6.5 on latest firmware.

    If you need more info than that I have lost all hope :)


    Cheers

  • John_LasersohnJohn_Lasersohn Moderator
    edited November 2020

    I will test this and post here about my results. One question for @RyanH and @RedNet - are the routes written for a split tunnel VPN (destination = remote LAN) or for tunnel all (destination = Any) ? Sometimes defects are specific to certain configs. I'll try both.

  • From the sounds of it, this issue is almost certainly bug ID GEN6-1275, we have a hotfix for this issue you can get from the support team.

  • Yes indeed, thanks @MasterRoshi - I also have confirmed that a release candidate version for our next release firmware contains the fix.

  • RyanHRyanH Newbie ✭
    edited January 2021

    Any tips on how to get this better solved with support? We got the hotfix for one of our NSA 2600s facing the problem.

    We have a few other models with the same problem and have opened cases with support referencing the ticket where they gave us the hotfix for the NSA 2600.

    Alternatively, do we know when the public release of the new firmware will be?

  • RyanHRyanH Newbie ✭
    edited January 2021

    @Saravanan @MasterRoshi @John_Lasersohn

    Can I get an update on the above? Support is refusing to provide us with the hotfix.

  • RyanHRyanH Newbie ✭

    Just noticed a whole section of my original comment was removed. Got to love being moderated for being honest about my experience with support.


    They are having us demonstrate the issue multiple times and suggesting pointless changes like dropping the encryption level on the VPN tunnel. It really is not something we have time to do when we know what the issue is. My coworker has spent hours on the phone trying to get the hotfix.

Sign In or Register to comment.