Site to Site VPN configuration troubleshooting - TZ 570 and TZ270
I've been setting up a site-to-site VPN on a pair of sonicwalls, both running Sonicos7+, and can't seem to get them to connect - or figure out how/where to dig deeper in logs to troubleshoot.
Remote site (main) has comcast business with a true static IP, test site has residential comcast on a dynamic IP. I've created a identical site to site VPN policy on both sonicwalls, IKE using PSK, PSKs match, Local and remote IKE FirewallIDs match and correspond to each other.
Proposals match (aggressive, group 5, AES 128, sha1), and I have the main site primary FQDN set as the IPSec gateway on the test site, 'keep alive' enabled, with the main site IPsec gateway just set up as 0.0.0.0 (since the test site has a dynamic IP)(edited)
The S2S VPN policy is enabled, and I've set VPN log levels to 'debug' to try and figure out what is keeping this thing from working. On the VPN status page, it just doesn't seem to do anything, no green disc like when I've set this up dozens of times before.
In the logs on the test site firewall, I just get one thing "Event 358 VPN Inform, IKE Initiator: Start Aggressive Mode negotiation (Phase 1) <source IP, remote IP, port 500 UDP>" and then after that, "IKE Initiator: Remote party Timeout - Retransmitting IKE Request." but no other errors.
On the main site's logs, nothing shows up - no evidence the negotiation is even beginning. But I've also never tried to troubleshoot site to site vpns using logs before, so maybe I don't have the right logging levels enabled?
Also, just for more information on my test site, I'm using a sonicwall plugged into a sonicwall to simulate being behind an unknown NAT device. But I've also plugged my test site's X1 port directly into the comcast modem to rule out those NAT-behind-NAT issues, but still no go.
anyways, figured it might be one of those 'type it out and the answer will come to you' type situations, thanks for reading my wall of text. if anyone has any ideas, or can point me to better resources on how to dive deeper on IKE negotiation logs, I've googled the heck out of it and haven't found much.
Best Answer
-
Euclidnet Newbie ✭
In this case, the packet was neither consumed, forwarded, or dropped - simply 'received'.
I did finally put two and two together however, and noticed that my NSA's X1 interface was sending out numerous unanswered ARP requests immediately after receiving the IKE port 500 authentication request from my TZ270 on its X0.
Just a cursory search of ARP issues lead me to conclude that the NSA device was causing a gratuitous ARP flood, which caused my ISP to block ARP requests during the IKE negotiation. Following this KB provided a resolution https://www.sonicwall.com/support/knowledge-base/sonicwall-sending-too-many-arp-requests/170505920233931/
The IKE negotation now proceeds through phase two, and I'm connected TZ270w-> ADTRAN Netvanta 1534 -> NSA2400 -> Internet -> TZ570.
Jeez.
0
Answers
@Euclidnet,
I think the best way to check would be by doing a capture for UDP 500, 4500 on the firewall and see if it is making through to the remote firewall.
Thanks!
Shipra Sahu
Technical Support Advisor, Premier Services
Hi @Euclidnet,
If your sonicwall is behind the NAT device, try to disable the NAT Traversal and check the VPN connection status and logs.
You need to contact Comcast business. They do not do bridge mode on their modems, thus the traffic destined for your business connection isn't hitting your firewall. If you can't ping the business public IP than they need to change their config. I've run into this before with them. Comcast sucks. Do NOT ask for bridge mode, their techs will try to do it and it will completely brick the modem. Again, Comcast sucks.
On the residential side, I'd suggest getting a dynamic DNS service setup on the firewall, then using the DynDNS FQDN as the IPSec gateway for the business side VPN configuration.
Start there, then we can discuss using better proposals for the tunnel.
Thanks for the helpful comments. I've synthesized suggestions in all of them, and figured out at least my first problem, and have ruled out a few bits of the puzzle. Here's a summary of what all I tried.
Next step - to figure out how to get the TZ270W connecting in its original situation - IE, behind my router and switch. Any suggestions here would be welcome. At my test site, I have the following setup :
Res. Comcast Modem -> X1 on a Sonicwall NSA4500 (old boy, a 2010 model) - X0 -> AdTran NetVanta 1534p Managed switch -> X1 on my TZ270W test equipment.
Back to square one, my logs now just show :
SENDING>>>> ISAKMP OAK AG (InitCookie:0x3242b3c07ac66212 RespCookie:0x0000000000000000, MsgID: 0xDB01000000000000) (SA, KE, NON, ID, VID(9))
IKE Initiator: Remote party Timeout - Retransmitting IKE Request.
So I guess my packets aren't making it through either the AdTran or the Sonicwall NSA4500... and yes, I did enable NAT traversal.
Thanks!
Good job troubleshooting the first part. As the first comment mentioned start with a packet capture. Do this on the NSA4500, looking at what it is doing with the VPN traffic from the TZ270.
Thanks. I know I'll solve this, and I know that's the next step - so sorry for the "newb" question but :
I've ruled out the Adtran switch, and have done a packet capture on the NSA4500. I see the ISAKMP port 500 packet come through, but then just..... nothing in the packet log. I'll attach my pcap, and a screenshot is below. After 30 seconds or so, another ISAKMP packet comes through.
I've set my logging level to 'debug' in the NSA, and am looking for routing information or what the device is 'doing' with that packet, but can't seem to find anything. No dropped packet announcements, et cetera. I don't live in Wireshark-land, so my skills here might be lacking a little - any chance you could point me in the right direction?
Wireshark is a step beyond what you need to look at right now. In the Sonicwall packet monitor, select the VPN packet and look at the packet details. There are essentially 3 options for processing of a packet: consumed, forwarded, or dropped. The packet should be forwarded, if not you need to determine why.