Client to Client Openvpn connects but no traffic (Solved)
-
Why don't you start a new thread. Probably you'll have another issue than Shaddoh.
10.0.8.2 (i.e. pinging from pfSense client, specifying OpenVPN client) can ping all the way through to 192.168.3.50. BUT! It can't ping 192.168.10.13, which is on the same physical network!
So I guess your client sites pfSense is not the default gateway in its LAN.
A site to site VPN should be established between two default gateways. If one site is not the default gateway in its LAN you have to add special static routes for the other sites LAN or do NAT. -
Sorry, what I meant is that I'm literally working on the same equipment as Shaddoh. We're working on the same project. :)
And yeah, it sure seems like the problem is the default gateway of the client computers, but it's not, I've checked that a dozen times.
In fact, what I'm experiencing now is that if I try to ping 192.168.10.13 (a computer on the client side's network) from the client pfsense itself as the tunnel IP, it doesn't work – unless the VPN is down! Then it works!
I did some packet capturing, and if the VPN is up, then a ping from 10.0.8.2 appears to come directly from 10.0.8.2 to 192.168.10.13, but of course 10.13 is a computer, not the pfsense router, so it doesn't know where 10.0.8.2 is. If I do that while the VPN is down, the traffic goes from 10.0.8.2 -> 192.168.10.1 -> 192.168.10.13 and back, so the ping goes through.
I've got something desperately wrong in the routing table on the client side, it appears, but I can't for the life of me figure out what it is. Why won't traffic to/from 10.0.8.x route through 192.168.10.1 first? The actual computers on 192.168.10.x network know nothing about 10.0.8.x.
This is the routing table of the client side while the vpn is up --
default [wan gw] UGS igb0
10.0.8.0/24 10.0.8.2 UGS ovpnc1
10.0.8.1 link#9 UH ovpnc1
10.0.8.2 link#9 UHS lo0
[wan network]/19 link#1 U igb0
[wan ip] link#1 UHS lo0
127.0.0.1 link#8 UH lo0
192.168.3.0/24 10.0.8.1 UGS ovpnc1
192.168.10.0/24 link#2 U igb1
192.168.10.1 link#2 UHS lo0
192.168.11.0/24 link#3 U igb2
192.168.11.1 link#3 UHS lo0
192.168.12.0/24 link#4 U igb3
192.168.12.1 link#4 UHS lo0
[dns 1] [mac of igb0] UHS igb0
[dns 1] [mac of igb0] UHS igb0 -
For reference, the 192.168.11.x and 192.168.12.x networks you see there are for two separate guest wifi networks. They're not relevant in this situation in that they don't need to be on the VPN.
-
Why won't traffic to/from 10.0.8.x route through 192.168.10.1 first? The actual computers on 192.168.10.x network know nothing about 10.0.8.x.
If the pfSense box is the default gateway on the computer there is no need to know 10.0.8.x, it will send responds to the gateway and pfSense knows the network.
I did some packet capturing, and if the VPN is up, then a ping from 10.0.8.2 appears to come directly from 10.0.8.2 to 192.168.10.13, but of course 10.13 is a computer, not the pfsense router, so it doesn't know where 10.0.8.2 is. If I do that while the VPN is down, the traffic goes from 10.0.8.2 -> 192.168.10.1 -> 192.168.10.13 and back, so the ping goes through.
The capture output would be easier to read.
You mean if the VPN is up the packet goes out the LAN interface with 10.0.8.2 and if the VPN is down it comes out with 192.168.10.1? -
Viragomann, thank you very much for your help to Shaddoh and I. Ended up fixing it by deleting the server and client setup and doing it step by step according to this article – https://doc.pfsense.org/index.php/OpenVPN_Site_To_Site. Previously we'd been trying to make it work based on the steps in this article -- https://doc.pfsense.org/index.php/OpenVPN_Site-to-Site_PKI_(SSL). I'm sure either ought to work, and I know for sure that I've gotten a 4-site setup doing the steps in the PKI/SSL article, but I don't have access to that setup to do testing, and I think the way we ended up doing it ought to work plenty well enough for what we're trying to do right now.
Thanks again, we appreciate the help stepping through the debugging process.