SonicWall Site to Site VPN - Can't reach IP's on other side of VPN

VPN
1

Okay, so here is what I have, and I’m not sure what exactly I’m doing wrong.

I’ve created a Site to Site VPN using a Sonicwall NSA 2500, and SonicWall NSA 3500.

On the Sonicwall 2500 which is my main office, I have Interface X1 configured as my WAN with a static IP from our ISP.

X0 is configured as our LAN and serving DHCP for that office. IP range is 192.168.168.1 - 192.168.168.167 (Gateway is 192.168.168.168)

On the SonicWall 3500 which is my remote branch, I have it similarly setup as follows:

X1 is my WAN setup with a static IP from our ISP.

X0 is our LAN, serving DHCP to everything on that end with a totally different IP range of 172.16.0.1-172.16.3.253 (Default gateway 172.16.3.254)

I’ve successfully opened a site to site VPN tunnel between these two by creating the VPN on both sides pointing to each other using ikeV2 with preshared secret. I’ve setup address objects on each end, that correlate to the other sides network ranges.

So, on the main branch side my vpn is pointing to Gateway 73.3.47.xxx (which is the correct static IP for my remote sonicwall). Destinations is the 172.16.0.0 -172.16.0.255 range. I do have a green light showing the link is active.

On the remote site my VPN is pointed to 73.217.253.xxx (which is the correct static IP for my main branch sonicwall). Destinations are set as 192.168.168.0-192.168.168.255. I do have a green light showing the link is active.

From the remote side i am trying to ping any known address on the main branch side for instance 192.168.168.21 which is one of my servers - and i cannot hit it. I cannot rdp to it… it just seems like it doesn’t get there.

I don’t show any rejection in my logs, or any indication as to whats going on…

Have I missed a crucial step, am I not realizing something i should?

Any ideas?

​

Thanks!

2

What are you address objects for the VPN policy exactly? Are you defining networks or simply ranges? If you are defining the ‘remote network’ objects as ranges. Try using them as network objects.

​

ie- 192.168.168.0/24 (or mask 255.255.255.0)

and 172.16.0.0/16

There are invisible internal routes built from those objects to choose the right VPN policy to route traffic to. It might be grumpy about trying to ‘route’ to a network range.

Is the traffic making it out the network via the tunnel? You should be able to tell with packet monitor. If so, are they being received on the other end? Again, packet monitor. You will of course need the right FW rules allowing VPN->LAN and LAN->VPN zone access. Guessing you’ve done that.

The green light only means the tunnel completed the IKE Phase 2, and the negotiation is complete. Not that traffic is passing back and forth.

I use a NSA 2650 to terminate ~23 Site to Site VPNs for several cellular modems routers. Each of the ‘remote’ sites is defined as a /29 network. Not an address range. IE 192.168.100.0 is the first network, then 192.168.100.8 is the next, and so on. This allows a router to route correctly.

3

On the 3500 side, you say that you have an “IP range of 172.16.0.1-172.16.3.253”

Yet, in your VPN policy you say that the “destinations is the 172.16.0.0 - 172.16.0.255 range”

No idea what IP you’re using to test, so I have no way of knowing if that’s a problem.

Hi, I’m a network professional, CCNA, CSSP, (blah, blah, on and on). Working with Sonic wall for going on 7 years now. Doing networking since before college, maybe 15 years?

Your subnet is wrong.

Also, is this a policy VPN, or a tunnel VPN?

Also, are you only transporting this one subnet across the link?

Also, have you checked your firewall rules?

Also, have you checked your logs?

Also, pcaps or it didn’t happen.

Sorry if that seems rude, I don’t intend to be, there’s just a lot of questions that I have when I look at this. I’ve been working with Sonic wall IKE and IKEv2 VPNs for almost 100% of the time I’ve administrated Sonic walls. I regularly attend their product training and even completed their professional level certification, then they changed everything about how you get it.

I’ve been burned and frustrated and elated and pleased by these problematic little boxes. I would like to help, so if you have more information and don’t want to share publically, just shoot me a private message. I’m happy to discuss it more.

Either way, be sure to fix that subnet assignment, and let me know how that goes.

Cheers.

4

Another area to check make sure your user groups have permissions set for lan and wan

5

So, my .02.

I typically use network type address objects, VPN zone, to refer to the full subnet of the remote interface. In your case, I would create 172.16.0.0/22, not a range equivalent to 172.16.0.0/24.

Next, try to ping progressively from the firewall across the VPN. Ping from 192.168.168.168 to 172.16.3.254. Does it reply? Let that answer add to your understanding.

My guess is that devices on both sides are refusing the connections due to host-level protections, and that your VPN is fine. Can be checked with an inbound NAT.

6

I’ll double check my firewall rules to share shortly, but pretty sure I have allow all both directions for vpn to lan and lan to vpn. Routing, how should I have that setup? That is probably what I have wrong.

7

Ok. Now let me see what i have here.

​

So, on each end I have an Address Object, configured as a VPN Zone, Type: Network, and then the network being 192.168.168.0 - Net Mask 255.255.255.0 (for the remote side pointing back to the Main)

Firewall Rules are as follows for LAN > VPN Priority 1, Source Any, Destination: Remote Network, Service Any Action Allow, Users Included: All, Users Excluded None.

Firewall Rules are as follows for VPN > LAN Priority 10, Source Remote Network, Destination Any, Service Any, Action Allow, Users included ALL, Users Excluded None.

There are no deny’s on that zone assignment at all at the moment.

-–

On the Main Side pointing back to the remote, I have it setup as a VPN Zone, Type: Network, 172.16.0.0 and 255.255.252.0

Same firewall rules on that side. Allowing anything to anywhere in both the VPN > LAN and LAN > VPN.

There are no denys for either zone assignment.

I’ll go look at the packet monitor and see what I have, and report back.

8

Hmm. That all matches up. I have a great deal of problems with Sonicwall’s invisible internal route table for the VPN policies. The packet monitor helped a bunch.

I would do tunnel interfaces if my remote devices supported it. Its much easier to manage routing polices than depending on the Site to Site to route as expected. IMHO. Even easier when you manage both sides.

9

Ok. So, the packet monitor reveals the following:

Dropping my pings Module 21 (IPSEC) Drop Code 186 Combuf Ip Ptr Null Error

Any ideas on what that means?

10

Drop Code 186 Combuf Ip Ptr Null Error

Is this the Encrypted packet (ESP) or a normal packet? There are options to breaks the flow down very finely in the advanced options. SO you can see a packet generate from the x0/x1 become encapsulated, and then be forwarded out of the WAN.

I don’t know for sure. But I think Combuf is shorthand for Comm Buffer. And the context is IPSEC I guess. Ptr is pointer in DNS land. And Null Error means a bad value is present.

Putting it all together. I’d say something in the IPSEC config is pointing to a bad value that looks present but is not.

I’d double check your configuration and Address objects. But sorry that one stumps me.

-–

And of course not a single page of documentation on Sonciwall’s site about what these words mean, lol.

11

LOL. tell me about it… I was like - great, glad you put up a list of what the drop code is… would be better if you put a link to WHAT IT IS.

So, i went ahead and changed over to a Tunnel Interface because both devices allow it.

Good news is that now my pings are getting out of my remote site, and into my main site… but now my packet monitor is dropping them because:
40 (Enforced Firewall rule), Module id: 25 (Network)

Only thing is I don’t have any firewall rules to deny traffic between the VPN and LAN or Lan to VPN so i’m kinda stumped as to what could be killing it now

12

Do you have routes on both sides? The module Network ID is all-encompassing. Could be a conflicting NAT rule, Route policy, or old S2S VPN policy. GL Look forward to hearing of your success tomorrow.

13

ROFL. Turns out you do still have to create the routing… I had not created the routing at all… Now that I created it, everything works as expected! Thx for all of the help!