I'm starting a new job and facing an IP conflict issue with some of our remote users who can't access network resources. We're using the IP scheme 192.168.1.X, and our VPN setup is Azure split-tunnel which doesn't accommodate any specialized NAT rules. The long-term solution would be to re-IP, but I worry about the legacy software that likely has hardcoded IP addresses in its configurations that I haven't tracked down yet. Additionally, we're aiming for CMMC 2 compliance, which complicates any switch to a more flexible VPN through our SonicWall due to the complexity of making it FIPS-compliant. I'm considering it might come down to using RDS, but I'd prefer to avoid that if possible. Any suggestions?
6 Answers
When I took on tech responsibilities for a newly merged company, I had to rebuild the entire internal network. Even with some chaos, it went smoother than expected just by simplifying everything. Complex workarounds can add more headaches. Focus on keeping it efficient and user-friendly to minimize internal friction.
Suggesting users re-IP their home networks is a bit extreme and could reflect poorly on us. It may be better to look for more feasible solutions.
One quick workaround while you're identifying the hardcoded IPs is to use a PowerShell login script to add a secondary static RFC-6598 address (100.64.1.x/24) to the users' NICs. This way, you can route only the corporate ranges through that interface, keeping your split-tunnel setup intact and resolving the IP clash. You can take your time with the re-IP process without having to resort to RDS.
If you’re looking at re-IPing in the end, consider readdressing both your organization’s and your remote users’ LANs. Introducing IPv6 could also alleviate a lot of these issues without needing to redo your IPv4 addresses.
We switched to Microsoft Global Secure Access to avoid these sorts of issues, since someone previously decided to use random subnets in the 192.168.0.0/16 range. It’s a smoother experience now.
You could set static routes on the client devices to ensure the traffic flows through the VPN interface for the conflicting IPs. If you’re working within a certain IP range, instruct users to adjust their DHCP settings to prevent further collisions.
I've implemented this in the past successfully. You can also consider lowering the interface metric on the VPN adapter, which usually helps.
Expecting users to change their DHCP range is pretty unrealistic. They won't do it.
I hadn’t heard of this solution before; sounds like it could do the trick!