"this QM message ID is lower" Sonicwall VPN tunnel error

I cannot seem to find any articles on the log error "this QM message ID is lower". This error is for the site-to-site VPN tunnel between Sonicwalls NSA240 and TZ200.

The site to site VPN tunnel keeps going up and down every few minutes.

Any help would be greatly appreciated,
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Blue Street TechLast KnightCommented:
Hi learn_it,

I understand that the tunnel goes down every few minutes but does traffic flow on it at all?

Verify you have the VPN setup per this Article: https://www.fuzeqna.com/sonicwallkb/ext/kbdetail.aspx?kbid=5857

I know this is a lot of info..but I laid it all out so you can go through each step in the troubleshooting process without waiting for me to get back to you. Try Step #1 and reboot both firewalls...then test. If the issue still persists go to Step #2 and so on. Let me know if you have any questions.

1. TCP Lifetime

This issue is seen mostly with SonicOS Enhanced; it’s not actually the VPN tunnel dropping, but rather the default TCP lifetime for the tunnel is set too low. On most SonicWALLs, its set for 5 minutes by default, which usually is not enough time for some applications and will disconnect a connection it sees as an open TCP connection (i.e. your applications) as inactive.

To remedy this issue, adjust the lifetimes on both sides of the VPN tunnel. Here’s how:
Log into the SonicWALL’s Management GUI.
Go to the Firewall > Access Rules page and choose the Matrix view style.
Click on the configure icon for the LAN > VPN zone intersection.
On the page that appears, you will see rules for the SonicWALL’s subnets to the remote SonicWALL’s subnets that were auto-created when you created the VPN policy.
For these rules (there may be more than one), click on the Configure icon at the right and click on the Advanced tab.
From there, adjust the TCP Connection Inactivity Timeout (minutes) field from the default of 5 to 60.
When done, click on the OK button to save and activate the changes.
If your VPN tunnel terminates to zones other than the LAN, you will need to also adjust those rules in both directions.

NOTE: Be careful adjusting the Default Connection Timeout (minutes) entry field found on the Firewall > TCP Settings page (or if it’s SonicOS Enhanced 2.5, the Firewall > Advanced page), as this applies to every connection through the SonicWALL, and may cause the connection cache to fill up and prevent subsequent connections. Please note that on both SonicOS Standard and SonicOS Enhanced, changing the Default Connection Timeout has no effect on existing Access Rules – it only affects Access Rules created after the change (i.e. only the new rules inherit the new setting, old rules remain unchanged).

2. VPN Policy Lifetime

There may be default settings on the SonicWALL that are causing it to prematurely tear down a VPN policy before the lifetime expires. To amend this, please adjust the following:
The default lifetime for each individual VPN Policy is set to 28,800 seconds (8 hours).
To make VPN policies last longer before they time out, log into the SonicWALL and click on the Configure icon for the VPN Policy to the remote SonicWALL.
On the page that appears, go to the Proposals tab and adjust each Life Time (seconds) field to a longer setting, such as 86400.
This change must be made on both sides; if they do not match, the devices will negotiate the lower of the two settings.

3. Dead Peer Detection

By default the SonicWALL is configured to perform Dead Peer Detection ("DPD"), which is a method to determine if the remote peer of a VPN policy is still active. By default the SonicWALL will send a small “are you there?” packet every sixty seconds. If the remote SonicWALL fails to respond to three of these packets (also the default setting), the SonicWALL will tear down the VPN tunnel. Sometimes these packets get lost, and sometimes the timers are set too short, but the result is the SonicWALL tears down a VPN tunnel that actually had no problems. You can try to fix this by doing two things – you can either shut off DPD on both sides, or you can adjust the DPD timers so that they are less aggressive. For example, to shut off DPD completely, go to the VPN > Advanced page and uncheck the box next to Enable IKE Dead Peer Detection. Make sure to do this on at least one side of the tunnel (for performance reasons, you may wish to not enable DPD on a SonicWALL that’s terminating many VPN policies).

If you find DPD useful (and it is), but simply want to adjust the timers, experiment with the Interval and Trigger Level (again, on both sides) until the VPN tunnel stops dropping. For an example of a SonicWALL set to send an “are you there?” every two minutes and to tear the VPN tunnel down after five consecutive missed replies (10 minutes total).

Another setting that may cause issues is the Enable Dead Peer Detection for Idle vpn sessions function, which is found on the same page. This feature is only in SonicOS Enhanced and is not in older firmware 6.x or SonicOS Standard. By default this option is disabled. This feature will tear down a VPN policy only if the peer stops responding to DPD requests. If there has been traffic activity on the VPN policy, the peer liveliness is implicit. This setting controls whether or not the DPD requests will be sent periodically on a policy that has seen no traffic activity. Unless your SonicWALL has a lot of remote sites and you’ve been advised to use this function, please do not enable it.

4. Keep Alive

In the VPN policy, this setting, if enabled, causes the SonicWALL to automatically negotiate a VPN tunnel and keep it permanently up (aka a ‘nailed up’ connection). By default this setting is disabled, which means that a VPN tunnel will only negotiate when the SonicWALL receives traffic destined for the network(s) behind the remote peer VPN gateway, and will keep the VPN tunnel active until the lifetime expires. To use this feature, click on the Configure icon for the VPN policy and go to the Advanced tab. Check the box next to Enable Keep Alive. If the device is running SonicOS Standard, it has a sub-option to Try to bring up all possible tunnels – check this box as well. When done, click on the OK button to save and activate the changes.

NOTE: it’s strongly recommended that this feature only be enabled on *one* side of the VPN tunnel – generally the smaller of the two sites of the VPN policy, and especially on sides that have dynamically-obtained WAN IP addresses. For example, a home SonicWALL TZ 100 with a PPPoE connection connecting to a central office NSA 3600 – Keep Alives would only be enabled on the home TZ 170.

5. Clean up Active Tunnels

By default, the SonicWALL has the Clean up Active tunnels when Peer Gateway DNS name resolves to a different IP Address feature enabled. The SonicWALL uses this when a VPN policy has been created and enabled that uses a fully-qualified domain name (FQDN) for the peer IPSec Gateway. This feature is most useful when the remote peer has a dynamic WAN IP address mapped to a Dynamic DNS name, and that IP address changes frequently. The SonicWALL will resolve FQDNs to determine if the IP has changed when the DNS TTL expires, and also when renegotiating VPN policies. The feature causes the SonicWALL to periodically query the DDNS record – if the IP address changes, the VPN tunnel will immediately be torn down. If neither side of the VPN tunnel has a dynamic WAN IP address, or if neither side is using FQDNs for the IPSEC Gateway, this feature should be deactivated. To deactivate it, go to the VPN > Advanced page and uncheck the box next to Clean up Active tunnels when Peer Gateway DNS name resolves to a different IP Address on each SonicWALL. When done, click on the OK button to save and activate the changes.

If none of this work...let me know and I troubleshoot this further with you.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Craig BeckCommented:
I'd agree with diverseit... it's probably the policy lifetime which is causing this.
Blue Street TechLast KnightCommented:

Any update on this?
Powerful Yet Easy-to-Use Network Monitoring

Identify excessive bandwidth utilization or unexpected application traffic with SolarWinds Bandwidth Analyzer Pack.

learn_itAuthor Commented:
This tunnel has been doing very well for over a year. It just started throwing the message and renegotiate non-stop a few days ago. In fact, it did seem to self-heal yesterday morning. No more messages of any kind - possibly an ISP issue?

Policy lifetime is set to 28800 on both ends at this time.
Blue Street TechLast KnightCommented:
Once you have gone through everything in my comment http:#a39494629. Let me know if the issue still persists.

Then you can try sizing the MTU by following these instructions: http://www.experts-exchange.com/A_12615.html
Craig BeckCommented:
Yeah if it was running fine with no config changes, then just started to fail, I'd look at the ISP side of things.

I've had a situation where the ISP decided to route my traffic through a different access switch which had a dodgy ACL applied.  This broke my IPSec traffic.  I've seen all kinds of issues with ISPs causing problems.  They recitfy it soon enough once you complain to them, but they'll never admit it.
Blue Street TechLast KnightCommented:
Yeah, I know...they are so shady!
Blue Street TechLast KnightCommented:
Any issue on this?
learn_itAuthor Commented:
diverseit, craigbeck

Thank you for your input in this thread. We have been doing well for a while now. The issue went away as unexpectedly as it appeared.

I have checked settings according to diverseit's comments. These are the directions we used during the initial tunnel setup. Everything checks out.

I consider this question resolved at this time since there is no issue and logs of it happening anymore.
Blue Street TechLast KnightCommented:
Glad I could help...thanks for the points!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Hardware Firewalls

From novice to tech pro — start learning today.