• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

IKE errors on my VPN

D

datastorm

Junior Member
Devices:
Sonicwall NSA 2400 running SonicOS Enhanced 5.8.1.8-57o
Sonicwall TZ 215 running: SonicOS Enhanced 5.8.1.8-42o
Sonicwall TZ 210 runnung: SonicOS Enhanced 5.8.1.8-57o



I have an issue with IKE transmissions taking a good portion of my bandwidth. I have a T-1 connection at 3 Mb/s with a sonicwall NSA 2400 working as the default gateway and running VPN’s to 6 satellite locations. VPN negotiations on 4 of these VPNs work fine, but I have 2 locations that the IKE negotiations time out when trying to connect to the Peer VPN device (TZ 215 and TZ210 sonicwall)

The Peer device (the TZ 215 & TZ 210) is connected to 2 Netgear MBR 1515 Wireless mobile broadband routers that are connected to 4G service from Verizon wireless. This set up requires the WAN IP address to be set via DHCP at this location.

Even though there is a consistent stream of IKE negotiations listed in the sonicwall logs the connections stay up and are functional. The connection does go down occasionally, mostly in the very early morning (3-5 am local time) otherwise the connection is solid. Between the 2 affected VPNs it can take up as much as 1.5 – 2 Mb/s of my bandwidth. Being that I only have 3 Mb/s available, this is way too much.

I have checked the logs again and do not find any instances where the IKE time outs were being reported, and found none, so the issue is not happening right now, but I fear it will raise its ugly head again soon.

First thought was that the sonicwall were having trouble with the DHCP assigned IPs for the peer devices, but my VPN’s are set to recognize the peers by DNS name, not IP addresses, so this should not really be an issue. Another thought was the tz 215 was just having trouble connecting over the Verizon network, but the VPN is active and I had general connections from my users at the remote location connecting with no issues during the times the errors were posting to the log.

Any ideas as to why IKE transmissions would be failing?

Any idea as to why IKE transmissions would take up so much bandwidth?

Any help would be appreciated,
 
It's odd, when you say IKE, are you speaking of phase 1 or phase 2? I'll assume phase 1 since most people call phase 2 the IPSEC phase..

IKE phase 1 is only used briefly to setup a single bidirectional SA(security association) between the two endpoints so that they can securely exchange the keys used in phase two (which is a set of two uni-directional SAs per connection). . .

Do you have a brief drawing of what this looks like so I can visualize it. . . and can you send me logs(use notepad find/replace to get rid of public IP's) and I'll have a look?

What are your session lifetimes for both phase1 and phase2? you mention that it's using DHCP for it's address, meaning only one side can be the initiator because it's a dynampic IP, which means it's using agressive mode, which is actually only 3 transactions instead 6 which would be used for main mode . . ..

are you sure that ike is FAILING?
 
Lithium381, thank you for your quick response, I have to apologize for my slow and feeble response.

I first noticed the errors on the sonicwall logs, but was too busy to address the situation, when I got back to it the errors were no longer occurring and they had been purged from the log file because of aging. (The device only keeps records in the log file for about 3 days before the quantity of entries pushes older items off the log)
So I have no log entries to post that show the errors I am curious about. I have been monitoring the logs on both sides of the VPN connection for the errors over the last week and have yet to find any. I realize without the logs we can't be 100% sure of the exact issue, but perhaps is there a way to test the integrity of our VPN connection in regards to the IKE negotiation? (other than: see the VPN is up and you can pass traffic across it without issue)

Session lifetimes are set to 28800 seconds for both IKE and IPsec proposals and yes it is using aggressive mode.

I have suspicions that IKE is actually failing and it may be just one attempt does not get answered inside the lifetime but a second attempt is succeeding, I do remember being able to ping items on that subnet even during the period the errors were being recorded.

I am gaining knowledge quickly on how the sonicwall devices operate and how VPN's are established and maintained, but I have to admit my knowledge is minimal and I hope I am conveying the information correctly.
 
Can you post the redacted logs?

ETA: Sorry, I see you have no logs to post.

Can you recreate the error? What traffic is being passed across the tunnel?
 
Last edited:
I'm asking about IKE failing specifically, or could it be that routing to the other endpoint has somehow been interrupted at some point? Try setting the IPSEC lifetimes a little bit shorter so they're not trying to renegotiate both at the same time... i see ipsec lifetimes at 3600 seconds (one hour) as opposed to 28800(8 hours) quite often.

when you see your logs from the events again, you'll notice it renegotiates a new session, and THEN tears down the old one.
 
Also, are you using tunnels with the encryption (route based VPN) or just matching traffic against a policy map (policy based vpn)
 
The VPNs are using route based encryption.

I will change the lifetime to a little shorter (1 hour) and see if it makes any noticable change. (if nothing else it will help illustrate the process for me)

(I am also exporting logs so I can have a paper trail of issues)
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top