Join the Conversation

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


Site to Site VPN configuration troubleshooting - TZ 570 and TZ270

EuclidnetEuclidnet Newbie ✭

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 (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.

Category: SSL VPN

Best Answer

  • Options
    EuclidnetEuclidnet Newbie ✭
    Answer ✓

    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

    The IKE negotation now proceeds through phase two, and I'm connected TZ270w-> ADTRAN Netvanta 1534 -> NSA2400 -> Internet -> TZ570.



  • Options


    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.


    Shipra Sahu

    Technical Support Advisor, Premier Services

  • Options
    AjishlalAjishlal Community Legend ✭✭✭✭✭

    Hi @Euclidnet,

    If your sonicwall is behind the NAT device, try to disable the NAT Traversal and check the VPN connection status and logs.

  • Options
    TKWITSTKWITS Community Legend ✭✭✭✭✭

    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.

  • Options
    EuclidnetEuclidnet Newbie ✭

    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.

    • 1st, on the business (Main) site, I wanted to ensure there were no problems with Comcast Business, or my modem there. (IE, Bridged mode issues). To verify this, I set up a Site to Site VPN between the Main site, and another Sonicwall I had at a 3rd site, where I knew site-to-site VPN connections worked.
    • This initially did not connect either, but now I was getting IKE negotiation errors in my Main Site logs. I discovered that I had a small mismatch between the Networks/Address ranges I had defined in my Test Site and Main Site. I had set the 'Local Network' on both sides to 'LAN Subnets' - which is defined as Address Object Type : Network. In my VPN policy, I had defined the 'Remote Network' on both sides as a range of IPs, which was properly defined - but the IKE proposals were being rejected since they both were not defined as a 'Network'. Super non-intuitive, and confusing. I have also not seen this problem documented anywhere else on the internet (be it Sonicwall's site, documentation, 3rd party sites) - so I figure it is worth mentioning.
    • Once I corrected the local and remote network types, my Main Site and 3rd Site connected! So, I have ruled out any problems with my Main Site network configuration / ISP.
    • Back to the Test site - I corrected this same problem on my test site, and made sure all settings and proposals matched. I was unable to connect. So, I disconnected all intermediary routers and switches, and hooked my Test site TZ270W firewall's X1 directly into my Residential Comcast modem.
    • Success - my Test site TZ270W is now connecting site to site to my Main site.

    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.


  • Options
    TKWITSTKWITS Community Legend ✭✭✭✭✭

    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.

  • Options
    EuclidnetEuclidnet Newbie ✭

    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?

  • Options
    TKWITSTKWITS Community Legend ✭✭✭✭✭

    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.

Sign In or Register to comment.