Issue with Global VPN users accessing remote VPN network

**EDIT 6/6/2019**
We went out yesterday and replaced the Site 2 SonicWALL SOHO250 with a TZ300 and it started working fine with the exact same configuration. We are going to send the SOHO back to see if it was bad. I thank you all for your assistance with this issue.

Hello everyone, been at this far longer than I care to admit, so I’m hoping someone can help me out here.

Let me start by giving an overview of what I got: we have a site with two locations connected via VPN. Site 1 uses a TZ300, and Site 2 uses a SOHO250. As far as the actual VPN connection between the two sites go, everything is working. I can ping devices on site 2 from site 1 and vice versa. No problems, right?

Well the client needs to be able to access some network resources (specifically, cameras and a customer database) remotely. Since they don’t want this data accessible on the internet, we set them up with the global VPN client. I have managed to get it set up so that they are able to VPN into the Site 1 network and access all resources there with no problems. The issue is that they are unable to access anything on Site 2.

Here’s what I have already done as far as configuration is concerned:-I have already added the remote site’s network to the VPN access list for the user’s account in the sonicwall.

-I have created access rules in both firewalls to allow traffic from appropriate zones to go through (Site 1 has a rule to allow VPN > VPN traffic from “anywhere” to site 2, and vice versa, and site 2 has rules to allow VPN > LAN traffic from site 1 to site 2 and vice versa).

I have used the packet monitor built into the sonicwall to see what is going on. When I ping from my remote system to a device on site 2 (10.10.2.200, let’s say), I do not get a response. The packet monitor shows that traffic is coming into the Site 1 sonicwall and being forwarded to site 2 (as expected), but when it arrives at site 2, it just stops dead. Note here that I do not receive a message stating that the packet was dropped; it just isn’t forwarded like I would normally expect to see. The only message I see is that the packet is “consumed”, which I assume means it is received by the sonicwall to be handled.

I checked the Log and there are no entries for ICMP packets (I made sure to enable all ICMP messages in the log monitor settings, just to be sure). It’s as if the device isn’t even registering that a packet came through at all, even though the packet monitor clearly shows that a packet arrived with its destination marked 10.10.2.200.

On a whim, I decided to start pinging the gateway (10.10.2.1, let’s say) and I was still getting the same issues as above; packet monitor shows the packet being consumed with nothing else happening afterwards.

I checked the Log again and this time saw an error which states “ICMP packet dropped due to Policy” with notes stating “policy not found for packet on Zones (VPN → LAN)”. As stated above, I do not see any instance of packets being dropped in the packet monitor, and I absolutely DO have a rule from VPN → LAN that allows traffic from Site 1 to Site 2’s local IP subnet. There is even a rule to allow management traffic through since I set up the site to site VPN tunnel to allow management traffic so that I wouldn’t have to go to each site manually to configure these things.

I’m stumped. I can’t figure out what it’s trying to tell me here. It sounds like a firewall issue but no manner of access rule configuration seems to satisfy the problem. I even created a rule to specifically allow traffic from my IP address to the device’s IP address and it still won’t allow me to access the device. I even made the network practically wide open allowing “any” connection from “anywhere” access to “anything” and it still tells me that no policy exists for zones (VPN → LAN).

Hopefully I explained that well enough. If anyone needs more information I will be more than happy to provide.

Thank you in advance for your time.

This sounds really awkward. “Consumed” generally means, that a packet was destined for the firewall appliance itself.

What are you filtering for, when using the packet monitor? The destination or the source ip? Also did you make sure “bidirectional packet monitor” is enabled?

Something is strange as you shouldn’t have to change anything on the firewall to allow access. Simply add the user to the remote network for access.

https://www.sonicwall.com/support/knowledge-base/?sol_id=170505963174776

TL/DR
Have you rebooted the routers yet? My sonicwall does goofy stuff from time to time and a simple warm reboot from admin fixes it right up.

Awkward’s a good term. I can’t say I’ve ever had an issue like this before.

I am filtering for Packet Type: ICMP and Destination IP. I have tried mixing it up, and even not applying a filter at all, but it generally doesn’t matter; I usually get the same results.

Bidirectional packet monitor is enabled.

At this point I’m starting to think there may just be something wrong with the device itself, though why the site to site VPN works just fine and this specific VPN setup isn’t working is what has me confused.

That’s what has me so confused. One of my techs pointed out to me this morning that we have this exact same setup at a different site and they have no issues, and we didn’t have to do any weird firewall acrobatics to get it working.
I’m really starting to think it’s this SOHO we have at site 2 that’s the culprit. Site 1’s sonicwall seems to be behaving exactly as I would expect for this scenario; it’s only once we get into site 2 that things get dumb.

Rebooting is usually my 3rd step; it unfortunately did not fix it. We believe the device is bad since swapping it with a different model got it working perfectly fine.

Question first: Is the site 2 site ipsec tunnel going over WAN Zone / the internet? What’s the interface / zone the tunnel is bound to on both sides? What’s the incoming interface shown in packet monitor for the incoming icmp packet?

And two thoughts out of the blue:

  • Is the subnet assigned to VPN client users overlapping with a subnet on site 2 by any chance?
  • Also if above is checked: Have you made sure there’s a route back to the subnet that’s assigned to VPN client users?

Any chance I could have a glance at a pcap of that packet capture?

When connected to the vpn. Have you tried pinging from the remote side you are trying to access to the computer on the global vpn?

Try pining from a machine or server from the remote site to the VPN pc and do a packet capture on both firewalls for that traffic.

Tunnel is bound to the WAN port on both sides; Global VPN is using the WAN port as well. Site to site VPN is working fine; if I’m actually on site at site 1 and ping anything on site 2, I get a response as normal (same the other way around as well). It’s only when using the Global VPN client that I am unable to access site 2.

To answer your other two questions:

  1. The VPN clients use the same subnet as Site 1 (x.x.1.0\24) which is different from site 2 (x.x.2.0\24), so there shouldn’t be any overlap there.

  2. Since the global VPN clients are operating on the same subnet as Site 1 (x.x.1.0\24), my assumption here would be to say ‘yes’ since the site to site traffic routes just fine between the two sites, but to be honest I don’t actually *see* any static routes that lead specifically back to site 1 or the VPN clients. Sorry if that wording is a little confusing.

Here’s a link to the packet capture. I am sending an ICMP packet from my personal computer (off-site) to a device on Site 2 (x.x.2.200) while connected via the Global VPN Client to site 1 (hope that makes sense; I know it’s really awkward but it is what it is I suppose). I have the filter currently set to only capture ICMP packets; no source or destination has been set.

https://imgur.com/a/BcW1flM

I will have to give that a try when we are out there again. There is only an NVR and camera system out at that remote site. The users out there use wifi on their phones for whatever else they need.

  1. Since the global VPN clients are operating on the same subnet as Site 1 (x.x.1.0\24), my assumption here would be to say ‚yes‘ since the site to site traffic routes just fine between the two sites, but to be honest I don’t actually see any static routes that lead specifically back to site 1 or the VPN clients. Sorry if that wording is a little confusing.

The tunnel is in policy based mode by default. Forgot about that. You can‘t see routes here because the communication is „routed“ via the configured security associations.

Sadly I don’t see anything weird right now. It‘s pretty late here. Will keep you in mind and tell you if I found anything else to check!

Is this packet capture from site 1? The request appears in ingress the X0 and then is consumed. In a policy based VPN that is expected behavior for it being sent over the tunnel (which makes numbered tunnel interfaces a little easier for troubleshooting). Do you have the applicable packet capture for the other site?

Things that came to my mind:

  • Hows the packet capture looking when you ping from site 1 to site 2 without using vpn client
  • Have you checked if the ping arrives at the destination and the system just isn‘t answering to this specific echo request for whatever reason?
  • Can you check if pinging the other way around works? Pinging the VPN Client fromt Site 2
  1. The VPN clients use the same subnet as Site 1 (x.x.1.0\24) which is different from site 2 (x.x.2.0\24), so there shouldn’t be any overlap there.

When you say this, does it mean that site 1 vpn clients and LAN devices share the subnet?

^(Hi, I’m a bot for linking direct images of albums with only 1 image)

https://i.imgur.com/KzHsGRZ.png

^[1](GitHub - AUTplayed/imguralbumbot: A reddit bot for linking direct images of single-picture albums) ^^| ^[2](imguralbumbot/README.md at master · AUTplayed/imguralbumbot · GitHub) ^^| ^[3](https://np.reddit.com/user/AUTplayed/) ^^| ^[4](https://np.reddit.com/message/compose/?to=imguralbumbot&subject=ignoreme&message=ignoreme)^^| ^[5](https://np.reddit.com/message/compose/?to=imguralbumbot&subject=delet%20this&message=delet%20this%20eq0k595)


  1. Source ↩︎

  2. Why? ↩︎

  3. Creator ↩︎

  4. ignoreme ↩︎

  5. deletthis ↩︎

Thank you for your assistance! I’ll keep working on it myself and let you all know if I find a solution.

This is from site 2; sorry for not specifying.

Sorry, didn’t look closely enough to see that it was ingress on X1. I’d expect to see another entry for it being forwarded out the X0 but that doesn’t not appear to be the case. I’d would have guess failed ARP lookup but it would appear that the packet above it was an ARP response from the destination. Can you see the ARP table being populated correctly?

Only other thing I could imagine is a bad NAT policy doing something and it not showing up since your packet capture my not catch it post NAT.

Do you have any custom NAT policies?

I do not. This setup is about as vanilla as I could get, aside from the VPN stuff.
I appreciate the help; we had a tech go out there yesterday with a different device (TZ300 as well) and everything started working fine. Setup is exactly the same. I’m thinking it’s either something wrong with these SOHO250s in general, or the specific one we got. We’re just gonna go ahead and replace it with the TZ300 and call it a day.

Thanks for the help though.