Client to Client Openvpn connects but no traffic (Solved)
-
This is site A. The public address has been blacked out
![routes at site A.PNG](/public/imported_attachments/1/routes at site A.PNG)
![routes at site A.PNG_thumb](/public/imported_attachments/1/routes at site A.PNG_thumb) -
This is site B. The public IP has been blocked out
![Site B routes.PNG_thumb](/public/imported_attachments/1/Site B routes.PNG_thumb)
![Site B routes.PNG](/public/imported_attachments/1/Site B routes.PNG) -
And yes, the objective is to view the file server at site A from site B
-
It seems, the sreenshots are not taken from the same connection. The firest shows the vpn server with 192.168.100.1 and the client with 192.168.100.2, the second shows the server has 192.168.100.5 and the client 192.168.100.6.
However, it looks like there is something miss-configured at the client.
Have you deleted any client specific override on server?
Post the client settings, please. -
Client side config file
-
Client side config page 2
-
Client over ride on the server side
-
If you only have one vpn client you don't need client specific overrides, as i've already mentioned. So you should delete it and enter the clients LAN subnet 192.168.10.0/24 into the "IPv4 Remote network(s)" box in the server config and the server sides LAN 192.168.3.0/24 into the "IPv4 Remote network(s)" box in the client settings.
If you have multiple clients you have to use client specific overrides, but you've it set wrong. At "IPv4 Remote network/s" you've to enter the client sides LAN 192.168.10.0/24 and at "IPv4 Local Network/s" the server sides LAN.
-
New client side config
![new client side.PNG](/public/imported_attachments/1/new client side.PNG)
![new client side.PNG_thumb](/public/imported_attachments/1/new client side.PNG_thumb) -
New Server side config. NOTE the client specific override has been deleted
![new server side config.PNG](/public/imported_attachments/1/new server side config.PNG)
![new server side config.PNG_thumb](/public/imported_attachments/1/new server side config.PNG_thumb) -
We are at the same state. I restarted the openvpn service on both ends after the change. The status shows as up, but data not passing through. Please let me know what further info I can post to help resolve this.
-
As you wrote in your first post:
@Shaddoh:From the router at site B I can ping Computers at site A.
From any computer on site B I can not ping anything at Site A.There are only two possible reasons for this behavior:
-
The pfSense at site B isn't the default gateway.
-
The firewall rules doesn't allow access. Check LAN rules at site B and OpenVPN rules at A.
-
The server at site A itself blocks the access from the other subnet. Try to shut down the servers firewall.
If you have no luck use packet capture from pfSense Diagnostic menu to check where the packets are dropped while you're pinging the server from a host at A.
-
-
The pfSense at site B isn't the default gateway.
The firewall rules doesn't allow access. Check LAN rules at site B and OpenVPN rules at A.
The server at site A itself blocks the access from the other subnet. Try to shut down the servers firewall.Sire B pfsense is the default gateway. It is the router being used for DHCP there. There is a modem in front of it but that is it.
I have checked the rules several times and unless I am skipping over something they are what appear to be correct. I can post pictures of the rules I have
Firewall is turned offNotes:
I read some other forum, where someone was asked to create an interface named openvpn and then create rules in there. What i did was use the wizard and it created rules under firewall>rules> openvpnUpgraded the site A pfsense to latest version. thought it may have been a bug or something. But did not help
-
These are firewalls on Site A the server side. Hosting openVPN
-
Hi, I'm working on the same VPN setup as Shaddoh. We went ahead and upgraded both pfSense routers to 2.3.2_1, deleted all the openvpn configurated and started over again, creating the openvpn setup with the wizard. Firewall rules look ok. Both client and server now see each others' tunnel IPs as the same (server is 10.0.8.1, client is 10.0.8.2) as opposed to the .1 .2 / .5 .6 mismatch we were seeing before.
Computer on Server's LAN network 192.168.3.50
Server LAN IP 192.168.3.1
Server tunnel IP 10.0.8.1
Client tunnel IP 10.0.8.2
Client LAN IP 192.168.10.1
Computer on Client's LAN network 192.168.10.13192.168.3.50 can ping all IPs through and including 10.0.8.2, but no further.
192.168.3.1 (i.e. pinging from pfSense server, specifing LAN interface) can ping through to 10.0.8.2, but no further.
10.0.8.1 (i.e. pinging from pfSense server, specifying OpenVPN Server) can ping through to 10.0.8.2, but no further.Obviously, traffic is flowing over the VPN, but from the server side, it can get to 10.0.8.2 but not from there to 192.168.10.x.
192.168.10.1 (pfSense client, specifying LAN interface) can ping through to 10.0.8.2, but no further. Unlike server -> client, in this direction the client pfsense LAN interface cannot see the tunnel IP on the server end.
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!I must have some routing issue, but I can't quite understand what it could be. 192.168.3.50 can get through to 10.0.8.2, but NOT to 192.168.10.1. Then 10.0.8.2 can get to 192.168.10.1, though it can't see 192.168.10.13, and obviously 192.168.10.1 can ping 192.168.10.13.
The problem seems to be getting from 10.0.8.2 to IPs that are physically on the same pfSense router, though it can connect to the LAN IP of that router.
-
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.