We didn’t design the network we inherited it from on prem IT. I am wondering why this works sometimes and other times it does not?
You may want to hire a network engineer yourselves;). Re-IP is not the only solution. Best practices? Absolutely. Should it be planned and done ASAP? Absolutely. Should someone get a slap on the wrist for not fixing during onboarding? YUP.
However adjusting IP pools for the VPN, split tunnel and utilizing NAT rules you can overcome this. Pretty basic. This will provide a working solution in the interim until you can re-IP.
I don’t understand how a new VLAN solves this. If you’re going to go through the trouble of setting up a LAN at all, it may as well be Re-IPing the existing one. It’s not overly difficult to setup an IP scheme that’s scalable, and will play nicely with others in a VPN setup.
That may, may, resolve the immediate VPN issue. But it won’t resolve all the other subtle issues like devices with preconfigured fallback IPs being plugged in and conflicting with existing network devices. Dell, HP/Aruba, NetGear, Ubiquiti, and a bunch more that I can’t bother to recall. He’s probably running some cheap crap router to have that subnet in the first place.
MacBooks coming from home to Office and holding onto their home DHCP reservations is an old favorite for good times. Suddenly the MFP is offline, or is it the CEO’s desktop? Why? Wait, it’s back! Nope is down again. What the heck is going on?
Got an onsite PBX? Send a VoiP phone home. Now we’ve got a party!
No business network should be configured on the first few 192.168 subnets. That network is broken.
I second this, networking is the weakest skill when training up techs. It’s the one thing I force down there throats, nothing work without a solid network. #ItsAlwaysDNS
I already said this in my reply and for security reasons we do not allow users to allow bridging of their local networks to the corporate network. We have multiple 10Gb transit connections for our office vpn pools that account for this extra traffic.
Because folks connecting from the 10.0.0.x or 10.1.10.x networks are fine. Or have a home router that uses a different IP scheme.
Re-IP the network - it wasn’t designed from the start, it was ‘here’s the defaults’ and never corrected.
This is the perfect time of year to fix it - most folks are off.
Possibly just the IP addresses in use conflicting/overlapping.
You could try moving the SSL VPN pool onto a totally new subnet like 192.168.235.0 and enabling ‘Tunnel All’ for NetExtender clients.
Might be a DNS issue. When VPN is connects it’s using corporate LAN DNS servers. If those IPs conflict with another device in a remote network it stops working. Remote users can’t resolve corporate resources, etc.
Don’t sweat it, plenty of 192.168.1.x corporate subnets still out there. Many did not need remote access until Covid and you had to get them all working remotely on 3/16/2020. And going to their office to re-IP the network was not an option.
So you onboarded this customer without identifying this risk, and pushing them to move to a supportable configuration?
This is the root cause of the problem, this should have been caught and addressed during onboarding, and if you don’t have somebody on staff who can identify these issues you probably need to find a network engineer consultant to help you avoid these issues in the future.
Why doesn’t it work sometimes and not others? Dumb luck, you’re split tunneling and some % of end users are on different common default subnets, so they work perfectly fine. My guess is 100% of the end users with a 192.168.1.0/24 home network are having some sort of problem using the VPN connection, or depending on how exactly the split tunneling is configured, 100% have the possibility to have this problem as soon as an IP conflict between the two networks pops up.
So you have 2 options.
- Fix the corporate network IP range to something that is VERY unlikely to conflict.
- Change the end users modems/routers to a different subnet, causing possible support liabilities when you break stuff in their home in the process.
I don’t know about you, but I don’t want to own support problems on the end users network, even for a short period of time. They aren’t my customer, and I don’t want any liability like their security cameras not working later that night when their home is broken, etc.
What better week to re-ip a network of this size than between Christmas and New Years? 
I’m going to disagree, if he and his MSP didn’t catch this problem during onboarding, what do you think the chances are they can pull off a in firewall NAT <> VPN setup without outside help?
I’ve built these solutions before between two large networks, it will for sure work, but seems like a lot more work than just going in and fixing a simple subnet of IP’s in a retail shop.
He’s probably running some cheap crap router to have that subnet in the first place.
Come on AccidentalMSP you know me better than that and what I say on this subreddit. It shows you didn’t even read the title of the thread, unless you are calling SonicWALL a “cheap crap router”
Moving the VPN subnet won’t solve the problem, not using split tunnel might, but will push 100% of internet traffic from the end users computer through the corporate firewall/internet, and I suspect they don’t have the bandwidth to handle that setup.
It’s not a DNS issue, it’s a network routing issue. DNS is just a phonebook that gives you an ip address, not connecting to the ‘correct’ 192.168.1.20 is always a routing issue.
So you onboarded this customer without identifying this risk, and pushing them to move to a supportable configuration?
This customer is a retail shop and never worked from home so it wasn’t an issue. With all of our remote access customers we have never had an issue with 192.168.1.x networks. This is the first time we are seeing this.
They may not be cheap, but they certainly are crap!
You’re right, I’d forgotten about Sonic wall by time I got that deep in the thread.
Sorry.
Short of a re-IP exercise, removing split tunnelling is about the only way I guess.
It’s surprised me how often we’ve found corporate networks sitting on 192.168.0 or 1 in the wild.
That was just an example of why it may work sometimes and not the others.
I have seen situations myself when a remote VPN user local IP overlapped corporate LAN subnet and it still worked fine. That’s with split-tunnel enabled.
VPN client creates on-link routes on the remote client PC. Based on those routes client PC can often route traffic correctly between remote corporate LAN and it’s local LAN, even if the subnets overlap.
It’s pure dumb luck if you haven’t seen this before if you have multiple customer networks on one of the most common default subnets.
If it’s a retail shop how much infrastructure could they possibly have to move to a new subnet?
And please tell me it’s not POS equipment, because the PCI-DSS compliance issues for allowing remote VPN into a PCI covered network would be a MAJOR problem.