OpenVPN - Unable to communicate through tunnel
-
Hi all,
Hopefully someone can point me in the right direction. As I feel like I'm going in circles a bit. This isn't my forté at all.
We've got 2 VM's, one running pfSense, and one running a basic test CentOS install. They are attached to the same LAN in the virtualisation platform (OnApp).
pfSense:
WAN: xx.xx.xx.xx
LAN: 192.168.0.15
CentOS VM:
LAN: 192.168.0.6- PfSense and the CentOS VM can ping each other
OpenVPN:
IP4 Tunnel Network: 192.168.3.0/24
IP4 Local Networks: 192.168.0.0/24, 192.168.3.0/24When I connect into the VPN from my local machine, I get assigned 192.168.3.6. I am able to do the following:
_- Load pfSense WebGUI on the LAN address 192.168.0.15- Ping that address (192.168.0.15)_
I cannot do the following:
_- Cannot ping the CentOS VM on 192.168.0.6- The CentOS VM also cannot ping my local machine on it's Tunnel IP 192.168.3.6_
I can understand why this is happening, because they are addresses in different subnets. But I cant understand why I can ping 192.168.0.15 (the pfsense LAN), but not the CentOS VM LAN on 192.168.0.6, even though those two can ping each other, and IU can ping pfSense.
Any ideas? I assume its something simple I'm missing here.
-
Why do you enter your tunnel network 192.168.3.0/24 at local networks?
However, this in not the issue.To get the communication work, you will need an oubound NAT rule in pfSense for LAN interface translating the VPN address (whole tunnel 192.168.3.0/24) to LAN address 192.168.0.15.
-
Sorry if I'm being a little dense, but exactly what are you trying to accomplish?
When you say:
When I connect into the VPN from my local machine, I get assigned 192.168.3.6. I am able to do the following:
- Load pfSense WebGUI on the LAN address 192.168.0.15
- Ping that address (192.168.0.15)
Do you mean connect to pfSense via OpenVpn from outside (via WAN) the pfSense network?
If so, you need only configure the pfSense OpenVPN server with the "IPv4 Local Network/s" ie. the subnets that should be made available to connecting clients.
One major thing to watch for:
WHENEVER POSSIBLE avoid using subnets like 192.168.0.x, 192.168.1.x, and 10.0.0.x for your LANs!Way too many stock routers and AP's use these addresses out of the box. You may even be running into this with your current home setup, which will cause all sorts of ugly to fix routing issues. The simple solution is to change one (and preferably both) subnets to something a little more distinct. This will save you all sorts of problems in the long run.
Let us know how it goes and keep at it, eventually the fog clears…. :D
-
Hi guys,
Thanks for the replies. The environment this is in isn't entirely normal. It will go on to function as a very bespoke and not widespread VPN service for a client, in his own private environment within his OnApp Cloud. The subnets used were mainly for testing as we need this to function as a sort of proof of concept.
I ended up using 192.168.1.0/24 as the tunnel, and 192.168.0.0/22 as the ip4 networks. And then NAT'd that /24 to that /22 on the LAN interface as suggested. It worked a treat. I knew the issue was likely that the client didnt know how to route to the private VM, but wasn't sure what or how to tackle it.
So thanks again, your advice has resolved the problem, and I can now get on and completely redesign it from the bottom up using more thought out networks now that I know it functions as intended.
Thanks,
Dave -
I ended up using 192.168.1.0/24 as the tunnel, and 192.168.0.0/22 as the ip4 networks. And then NAT'd that /24 to that /22 on the LAN interface as suggested.
192.168.0.0/22 includes 4 "/24" subnets:
192.168.0.0/24
192.168.1.0/24
192.168.2.0/24
192.168.3.0/24So it overlaps with the tunnel 192.168.1.0/24
That is not going to be a happy thing. As you say, you can "completely redesign it from the bottom up using more thought out networks".