Help with OpenVPN connections to remote LAN

[Metro]

Hello Everyone,

I hope everyone is staying safe during this crazy time in our lives.

Like many of you, I have been asked to allow for remote connections by employees to their work desktops. I am attempting to set up the OpenVPN server on our Asus RT-88U running 384.15.

I can connect successfully via the OpenVPN Windows client from my home to this remote location, but I'm unable to connect to any of the LAN resources. I see many, many other posts like this one and I've tried many of those solutions, but none have seemed to work.

Here are my OpenVPN server settings:

The only problem that I can foresee is the fact that both my home LAN and this remote LAN run on the 192.168.1.X IP range. I see lots of advice not to do that, and while I certainly can go about changing all the IPs on my home network not to conflict, I can't realistically ask my employees to do the same. I suppose I could also change all the IPs (many static) and DNS entries on the work network, but that sounds really painful and not something that seems very feasable.

Anyways - I've also tried opening Windows Firewall ports on a remote test machine to all IPs in the 192.168.10.x range, but that also didn't seem to help.

Can anyone point me in the right direction? Do I need to set up some sort of route? I'm really reaching the end of my abilities and a somewhat tight timeline to get this to work.

Thank you for any help you can provide!

 

[bbunge]

Hello Everyone,

I hope everyone is staying safe during this crazy time in our lives.

Like many of you, I have been asked to allow for remote connections by employees to their work desktops. I am attempting to set up the OpenVPN server on our Asus RT-88U running 384.15.

I can connect successfully via the OpenVPN Windows client from my home to this remote location, but I'm unable to connect to any of the LAN resources. I see many, many other posts like this one and I've tried many of those solutions, but none have seemed to work.

Here are my OpenVPN server settings:
View attachment 22104

The only problem that I can foresee is the fact that both my home LAN and this remote LAN run on the 192.168.1.X IP range. I see lots of advice not to do that, and while I certainly can go about changing all the IPs on my home network not to conflict, I can't realistically ask my employees to do the same. I suppose I could also change all the IPs (many static) and DNS entries on the work network, but that sounds really painful and not something that seems very feasable.

Anyways - I've also tried opening Windows Firewall ports on a remote test machine to all IPs in the 192.168.10.x range, but that also didn't seem to help.

Can anyone point me in the right direction? Do I need to set up some sort of route? I'm really reaching the end of my abilities and a somewhat tight timeline to get this to work.

Thank you for any help you can provide!

First, change the default port to something else. Then, change the VPN subnet back to the default 10. something. Should work.

 

[Metro]

First, change the default port to something else. Then, change the VPN subnet back to the default 10. something. Should work.

Thank you, I’ll give that a try now. Can I ask why you recommend changing the default port?

 

[Martineau]

Hello Everyone,

I hope everyone is staying safe during this crazy time in our lives.

Like many of you, I have been asked to allow for remote connections by employees to their work desktops. I am attempting to set up the OpenVPN server on our Asus RT-88U running 384.15.

I can connect successfully via the OpenVPN Windows client from my home to this remote location, but I'm unable to connect to any of the LAN resources. I see many, many other posts like this one and I've tried many of those solutions, but none have seemed to work.

Here are my OpenVPN server settings:
View attachment 22104

The only problem that I can foresee is the fact that both my home LAN and this remote LAN run on the 192.168.1.X IP range. I see lots of advice not to do that, and while I certainly can go about changing all the IPs on my home network not to conflict, I can't realistically ask my employees to do the same. I suppose I could also change all the IPs (many static) and DNS entries on the work network, but that sounds really painful and not something that seems very feasable.

Anyways - I've also tried opening Windows Firewall ports on a remote test machine to all IPs in the 192.168.10.x range, but that also didn't seem to help.

Can anyone point me in the right direction? Do I need to set up some sort of route? I'm really reaching the end of my abilities and a somewhat tight timeline to get this to work.

Thank you for any help you can provide!

Any justifiable reason why you have explicitly configured the VPN Server access credentials to ONLY a UserID/Password combo, rather than the (default) secure Certificate authentication method?

 

[Metro]

Any reason why you have explicitly configured the VPN Server access credentials to ONLY a UserID/Password combo, rather than the (default) secure Certificate authentication method?

To be honest, just for initial testing. I’ll ratchet up to a certificate method once I’ve locked in successfully connecting.

Thanks for spotting that.

 

[Metro]

First, change the default port to something else. Then, change the VPN subnet back to the default 10. something. Should work.

Wow, that worked. I'll be honest, I have no idea why it worked.

I... think I'm good now?

Martineau, I promise I'll switch to using certs now.

Thank you again!

 

[elorimer]

1. On the General tab, make sure the access is LAN and not Both. No need for non-LAN internet traffic to use up your tunnel and work internet bandwidth.
2. Don't get into changing the IP scheme on the work network on the fly like this, but do consider changing this when you have some time and it isn't so critical. It is easier to ask home people to move their home router off the 192.168.1.1--lots of manuals will show how.
3. You might disable compression. RDP will already be compressed.
4. You also might turn off client specific options and the client-client access. Do you need remote user 1 to be able to contact remote user 2 directly as opposed to through a LAN resource?
5. Everyone can use the same user/password combination, but if you want only some people to have access to some resources, you can get a little fancy with different users/password combos.
6. Also, even for initial testing I'd follow Martineau's advice. That is all about the connection and you've done that. It isn't simpler to do it your way.

 

[elorimer]

Thank you, I’ll give that a try now. Can I ask why you recommend changing the default port?

The idea is that there is a world of hackers out there banging on port 1194 to try to get into your network. I don't bother because they are unlikely to have the certificate and the passwords and OpenVPN is pretty secure.

 

[Metro]

1. On the General tab, make sure the access is LAN and not Both.
2. Don't get into changing the IP scheme on the work network on the fly like this, but do consider changing this when you have some time and it isn't so critical. It is easier to ask home people to move their home router off the 192.168.1.1--lots of manuals will show how.
3. You might disable compression.
4. You also might turn off client specific options and the client-client access. Do you need remote user 1 to be able to contact remote user 2 directly as opposed to through a LAN resource?
5. Everyone can use the same user/password combination, but if you want only some people to have access to some resources, you can get a little fancy with different users/password combos.
6. Also, even for initial testing I'd follow Martineau's advice. That is all about the connection and you've done that. It isn't simpler to do it your way.

Fantastic. Thank you.

A few questions/comments, if I may:
1. I've set it to both, and I understand that routes all traffic through the router. I'll switch that back to LAN only now that I have a working solution.
2. At a less critical time, yes, I will move the work network. I have several good reasons to do so.
3. Is this due to a resource issue on the router or due to compatibility (or something else entirely)?
4. No, you're right, they don't need to. I thought that might be the key to connecting to LAN network resources, but I'll turn that off.
5. Thank you. I haven't decided how to proceed yet.
6. I humbly take your's and Martineau's advice. I'll leave that on in the future.

Thank you again!

 

[elorimer]

3. Is this due to a resource issue on the router or due to compatibility (or something else entirely)?

Compression is said to expose a vulnerability in the encryption. For your purposes, it adds overhead to what the router is handling, on top of the encryption, and if folks are RDPing into their work stations, the traffic is already compressed. If you have one or two users, it may not be a big deal, but if you have 20 or so, it might.

 

[elorimer]

1. I've set it to both, and I understand that routes all traffic through the router. I'll switch that back to LAN only now that I have a working solution.

One thing on this. If your users will now be used to VPNing into the mothership, you might also find this is a good way of securing their internet access when they are in a public hotspot or airport (hah!). In that case, you can leave it at both but send to them two configurations, one like that for hotspots, and one for home access that has an instruction to ignore the tunnel for other traffic. Add to the configuration "pull-filter ignore redirect-gateway" to do that.

 

[martinr]

Wow, that worked. I'll be honest, I have no idea why it worked.

I can tell you why it worked: because a lot of energy and effort has been put into making this so simple that you’re better off not knowing anything about PKI, lest you be tempted to tinker. All you need to do is export the .ovpn to your client device and usually it works without a glitch. I think it’s one of those cases where the less you know the better, and, certainly, one shouldn’t start digging on the Internet because there’s a lot of totally out-of-date stuff on creating certs and keys, all unnecessary nowadays.

 

[distilled]

I can tell you why it worked: because a lot of energy and effort has been put into making this so simple that you’re better off not knowing anything about PKI, lest you be tempted to tinker.

And as a user who has never once shied away from rolling up my sleeves and diving in to fix things that weren't broken and spending the rest of the day trying to undo my "fix", I appreciate the fact that Merlin has made so many things brain-dead simple.