Sonicwall - IKE Initiator Remote Party Timeout

tstrip007

I have an old sonicwall TZ-190 running SonicOS Enhanced 4.2.1.4-7e. I have three VPN policies all with Cisco ASA's. We recently had a ISP go down and since they got back up, I cannot get these policies to connect.

My only thought at this time is that the ISP could be blocking UDP 500 or ipsec 50. However, I ran nmap scan for the gateway ip and it says port 500 is open.

Scratching my head here. I have been referring to these troubleshooting steps any help appreciated. Thanks!

Check the following:
.. Network connectivity between the units. (Hint: Try to access remote unit HTTPS management console from a host behind the local unit)
.. ‘Disable this SA’ box is not checked in SA of IKE Responder.
.. IPSec Gateway address in Initiator SA specifies WAN address of IKE Responder
.. IPSec Gateway Name (if used) resolves to WAN address of IKE Responder
.. IKE Access Rules are enabled on both SonicWALLs.
.. No other firewalls in path blocking IKE (UDP 500) or IPSec (IP 50) protocols.
.. Contact ISP to see if they are blocking IKE (UDP 500) or IPSec (IP 50) protocols.

mayhem87

Could be a hung SPI. Can you clear the ike and ipsec SA's on both firewalls for the peers?

tstrip007

I cant because they are client firewalls but I know the peeps who can. Thanks.

gespenstern

Are you positive that UDP 500 is open? I mean, since UDP is connectionless it's not reliable and function of controlling connection lies on upper layer protocols, if you are just probing then there's no upper level protocol, unless some specific nMap or whatever tool you are using has upper level protocol implementation and can exchange messages with other party knowing that this certain specific protocol (IKE in this case) is listening and replying on the other end.

It would be beneficial to try to connect both devices using alternative channel. When I was a field engineer I had a field laptop with me with CDMA modem on it that I could use as a temporary internet channel to see if ISP is blocking something. If you have some similar thing set up you can try it and if it goes well -- it's already enough to call for support, just tell them that your IPSec doesn't go through without going into specifics such as whether you think that IKE is blocked or ESP is blocked or NAT-T ESP on UDP 4500 is blocked or whatever, thus forcing them to check everything IPSec related.

So far it looks pretty much as UDP 500 is blocked especially if you can confirm that on the other end there's nothing in IKE logs when you attempt to establish a connection.

tstrip007

Thanks, got a ticket open with the ISP. I have the same VPN tunnels established at another location of mine that are using a different ISP. They have not gone down. I have also tried creating a tunnel from my sonicwall at bad location A to the SW at good location B and they will not connect.

Guess if the ISP comes back saying that the ports are not blocked I will look into changing the gateway IP to my other provider. Trying to avoid this as it takes along time to get firewall changes done with my clients. They are slow and go through a long approval process.

tstrip007

Issue resolved. Turns out that my network engineer upgraded the firmware to a load balancer in the middle of the night without telling me then wasnt in for a week. The SW was sitting behind the LB. The LB had static routes configed and when the unannouced upgrade happened, the routes were removed. So i could send traffic but not recieve ,hence why I thought the ISP was blocking.

gespenstern

That's why change management should be in place. Glad that your issue was resolved!