Can't browse to computer on client-end of openvpn
-
Our local network is 10.100.10.x, and it just so happens that the remote network that the client lives on (WAN connection) is 10.100.10.x. Our tunnel network is 10.5.2.0/30 and pretty much everything works fine, but for some reason computers on our local network are unable to see the computers on the other side of the VPN. Is this because the remote network WAN happens to share the same network addressing as our local addressing? Should it even matter what kind of addressing the remote network uses? We're using a peer-to-peer shared key setup if that makes any difference.
Thanks!
Mike -
The same networks on both sides of the VPN will cause routing issues at each side of the VPN link itself. Assuming that the two VPN devices are also hosting the routing point/gateway for each of the two sites, the two networks will not be able to pass traffic across the VPN link as the routing points on both sides see that the 10.100.10.0 networks live on the inside interface and not across the VPN tunnel.
-
Would you have any suggestions on how to possibly get around this? I don't think our pfSense appliance at the office is doing the routing or acting as the gateway for the office (sorry, I'm not the network admin), I believe that is handled by a separate router, nor does the office pfSense appliance live on the problematic network - it's just that traffic that originates from the problematic network eventually gets routed to the pfSense appliance acting as the OpenVPN server, which is then forwarded over the VPN to the client. As for the other end of the VPN, it's just a netgate appliance sitting on any network we happen to put it on in the field with one computer connected to it so that the field computer can have connectivity to our office.
I'm not sure if any of that makes any difference or if we're just screwed regardless. Would the only option be to ask the host location to lease the remote pfSense appliance a different IP that doesn't conflict with ours at the office?
So here is where my ignorance really shows - why would the remote network addressing cause the VPN to malfuncction. I would have thought that whatever is happening outside of the VPN should be insulated from what happens within the VPN and traffic flowing over the VPN connection would be forwarded to the client's LAN port regardless of the addressing on the WAN side.
Thanks!
Mike -
No worries at all, remember there are a TON of actual network engineers that couldn't get this far either.
In my opinion, for what its worth, there are ways to get around it but they get pretty complicated in the long term with sustainment in mind, meaning that there is no easy way to get this working with the configurations that are currently in place.
Out of curiosity, Whats keeping you from changing the IP Scope of your site, instead of asking the remote office to change theirs?
*To offer some transparency, one thing that could be considered is running a one-to-one nat across the VPN, but it could make sustainment a bit tedious in the long run. Just providing that as a possible fix for your problem.
-
No worries at all, remember there are a TON of actual network engineers that couldn't get this far either.
Ha! Thanks, I'm trying :)
In my opinion, for what its worth, there are ways to get around it but they get pretty complicated in the long term with sustainment in mind, meaning that there is no easy way to get this working with the configurations that are currently in place.
So, we'll be having a bunch of client appliances out at in the field (~20-40) so I'd really like to keep this as simple as possible. I'm keeping my fingers crossed that we don't run into more locations that happen to use the same network addressing.
Out of curiosity, Whats keeping you from changing the IP Scope of your site, instead of asking the remote office to change theirs?
The problematic network is our server VLAN :( So, we've got DCs, VMs, etc that are all hosted on that network, so changing that isn't really an option. We're actually blocking the client from accessing our server network as we want to limit outside access, but we want to be able to run scheduled tasks and do performance monitoring from that network to the clients in the field.
*To offer some transparency, one thing that could be considered is running a one-to-one nat across the VPN, but it could make sustainment a bit tedious in the long run. Just providing that as a possible fix for your problem.
Yeah, like I mentioned above, simplicity is ideal, especially when we're having to maintain a lot of these appliances. It looks like the easiest approach might be to see if the hosting site is willing to put us on a different network. We could care less what it is as long as it gives us access to the Internet.
thanks!