VPN on 192.168.1.x subnet issues

Jonas

Big client with this setup:
1. Internal network, 192.168.1.x
2. Having AD, DNS and so forth internally
2. Site-to-site VPN to hosting center, with replication of above servers.
3. Employee IP-sec VPN, with MFA through e-mail.

The issue:
1. 192.168.1.x is often the employees subnet as well.
2. Some employees cannot reach the DNS when opening the tunnel, thus waiting for the MFA-email that never arrives. Probably because their TV or something else share IP-address.
3. I push the DNS server of the hosting center on different subnet, to the client.
4. But, I cannot reach this DNS through the tunnel.

I can, change the entire network at the client from 192.168.1.x and fix this issue, client is NOT happy about this.

I would like to "just" be able to reach the DNS server on the other VPN to the hosting, while connecting with the employee VPN. I am pushing this information to the employee as soon as they connect. But it's unreachable.

Probably a rule, a routing or something else I'm missing. But cannot really figure it out.
Any advise?

By the way. Internally there is access through site-to-site tunnel to hosting center.
Also. Employee VPN is working perfectly using the internal DNS, but to prevent issues I need to use the DNS server in the hosting center.

mMontana

Jonas said:

Any advise?

Welcome to the world of bad network space planning. You're welcome to join the club. Been there, done that, didn't got the t-shirt.

Option 1: completely change your current network setup from 192.168.1.0/24 to something else. It's long, painful, generates anger and feeling of not being able to solve the issue; it will put you into position to backup before, planning while backup is running what configuration changes and in which order, considering possible to have to roll back the settings to 192.168.1.0/24 during the path so backup the configuration of everything before start (like printers, switches, APs, and so on).

This is the solution. Because everything into future will not run into 192.168.1.0/24 subnet issue anymore. Be careful with the subnet you're going to use, the less comfy and easy to write, the less likely you'll encounter in your future. For instance, the last subnet transpose i did was on 10.99.10.0/254.

Every other trick/patch/wannabesolution may have some big or little downsides, so be smart, try to plan "on virtual" the thing before doing something.

Trick 1: VPN SNAT

https://mysupport.zyxel.com/hc/en-us/articles/360003321659--ZyWALL-USG-How-to-configure-VPN-SNAT-on-Zyxel-gateways

This will translate subnets for the VPN endpoint.

For instance, the "fake Subnet" will be 192.168.243.0/24. From the VPN Endpoint you'll have to look for the fake subnet, and the firewall after that SNAT will look for the last octed on 192.168.1.0/24.

But this won't save the issue for applications: if your DNS will be asked for A record about myserver.mylan.loc which is 192.168.1.20, it will answer the same thing if query starts from the VPN Endpoint. Unless your firewall is not used in any way as DNS Server into LAN1, so you could write the most useful hostnames for VPN Endpoint into firewall with the translated address. Side trick could be to use only IPs, but most depend on applications. Moreover... If the VPN client goes in and out the LAN1 network, things are going to be a bit messy if you're referring too much to IP Addresses.

Jonas

This client... is.... hmmmm... not easy.
No way am I gonna get permission to change the network setup.
I tried for 15 years, no cigar.. - I had to deal with manually setting up VPN clients, changing employees home network and do anything to make it work while not touching the company network. 15 years ago it was easy with 10 employees.
Now they are 150, multiple servers, giant building with loads of networking equipment and they need MFA to happen. Lucky me I got this weekend to implement it.

I have to somehow make everything work for everybody without 150 potential support-cases on my neck after introducing the MFA.
Tests have went surprisingly well, considering.
Greenbow VPN, get config from server, open VPN, click the mail and the link. Done. Except for around 20% of the test-persons. Which translates into 30 likely issues on Monday.
Their network access gets blocked while waiting for the autorisation mail.

Why that happens might be an issue with the DNS servers IP-address(most likely) or the gateway address.

I will go for SNAT and point them to another DNS on a remote network, connected via a site-to-site VPN.

Thank you so much for your advise. I never setup SNAT before, it should be fun ;-)

I think, as you say, no matter what, it's gonna be a bit messy.

mMontana

Jonas said:

This client... is.... hmmmm... not easy.

Now they are 150, multiple servers, giant building with loads of networking equipment and they need MFA to happen. Lucky me I got this weekend to implement it.

Customers, for one reason or another, don't want to be easy, because you are the "easy" path for their needs.

If you're willing to change gear for this arrangement (192.168.1.0/24) IMVHO you have to "create" simple name for the problem (so the customer will know, consider $CrappyNetwork$ as placeholder), you should have a quotation for solve the problem (x 1.8 for having enough time for troubleshooting) and you have to add on any report which they won't pay for solve it as first row "Due to $CrappyNetwork$, the subsequent tasks had to be done..." After enough reports, an accountant will compare the quotation for subnet change with the quotation of your invoices, choosing which one will be thinner the next year.

Jonas said:

Thank you so much for your advise. I never setup SNAT before, it should be fun ;-)

I think, as you say, no matter what, it's gonna be a bit messy.

Wish you best luck, but... .... test test test test is the way. Don't go "live" without crushing all the issues.