Openvpn site-to-site: client cannot ping openvpn server and server lan

[ccrr10]

Dear pfSense community,
I set up an openvpn server on a pfSense gateway and an OpenVPN client on another pfSense gateway so as to implement a site-to-site openvpn. The client connects to the server and ping the openvpn server and its LAN and all the devices connected to the server openvpn lan. While the server and the devices connected to its LAN cannot ping LAN client and the devices connected to it.

The server subnet LAN is 192.168.10.0/24, and has access to the internet via two ADSL lines. The wan1 is 192.168.99.0/24 while WAN2 is 192.168.88.0/24. I configured a Load Balancing these two WAN connections.

The client's subnet is 192.168.8.0/24. The ping client also LAN wan1 and WAN2.

The subnet of the lan openvpn is 172.16.23.0/24.

The /var/etc/openvpn/server1.conf configuration file is as follows:

**dev ovpns1
verb 1
dev-type tun
tun-ipv6
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-128-CBC
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 192.168.88.102
tls-server
server 172.16.23.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc/server1
ifconfig 172.16.23.1 172.16.23.2
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'doppiacr' 1"
lport 1194
management /var/etc/openvpn/server1.sock unix
ca /var/etc/openvpn/server1.ca
cert /var/etc/openvpn/server1.cert
key /var/etc/openvpn/server1.key
dh /etc/dh-parameters.1024
crl-verify /var/etc/openvpn/server1.crl-verify
tls-auth /var/etc/openvpn/server1.tls-auth 0
comp-lzo adaptive
topology subnet
push "route 192.168.10.0 255.255.255.0"

push "route 192.168.99.0 255.255.255.0"

push "route 192.168.88.0 255.255.255.0"

route 192.168.8.0 255.255.255.0**

The client configuration file is as follows:

verb 3
dev-type tun
tun-ipv6
dev-node /dev/tun1
writepid /var/run/openvpn_client1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-128-CBC
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 192.168.55.7
tls-client
client
lport 0
management /var/etc/openvpn/client1.sock unix
remote qualcosa.no-ip.org 1194
ca /var/etc/openvpn/client1.ca
cert /var/etc/openvpn/client1.cert
key /var/etc/openvpn/client1.key
tls-auth /var/etc/openvpn/client1.tls-auth 1
comp-lzo adaptive
resolv-retry infinite

The openvpn server routing table after the client connection is as follows:

IPv4 Routes
Destination Gateway Flags Use Mtu Netif Expire
default 192.168.88.254 UGS 214294 1500 re1
127.0.0.1 link#8 UH 516 16384 lo0
172.16.23.0/24 172.16.23.1 UGS 0 1500 ovpns1
172.16.23.1 link#9 UHS 0 16384 lo0
172.16.23.2 link#9 UH 268 1500 ovpns1
172.16.24.0/24 172.16.24.1 UGS 0 1500 ovpns2
172.16.24.1 link#10 UHS 0 16384 lo0
172.16.24.2 link#10 UH 712510 1500 ovpns2
192.168.8.0/24 172.16.23.2 UGS 0 1500 ovpns1
192.168.10.0/24 link#3 U 0 1500 re2
192.168.10.1 link#3 UHS 0 16384 lo0
192.168.55.0/24 172.16.24.2 UGS 6 1500 ovpns2
192.168.88.0/24 link#2 U 2041166 1500 re1
192.168.88.102 link#2 UHS 0 16384 lo0
192.168.99.0/24 link#1 U 2043033 1500 re0
192.168.99.5 link#1 UHS 0 16384 lo0
208.67.220.220 192.168.88.254 UGHS 1350 1500 re1
208.67.222.222 192.168.99.1 UGHS 1350 1500 re0

The routing table of the client is as follows:

IPv4 Routes
Destination Gateway Flags Use Mtu Netif Expire
default 192.168.55.254 UGS 22707 1500 re0
8.8.4.4 192.168.55.254 UGHS 0 1500 re0
8.8.8.8 192.168.55.254 UGHS 0 1500 re0
127.0.0.1 link#7 UH 115 16384 lo0
172.16.23.0/24 172.16.23.2 UGS 0 1500 ovpnc1
172.16.23.1 link#9 UH 1864 1500 ovpnc1
172.16.23.2 link#9 UHS 0 16384 lo0
192.168.8.0/24 link#3 U 60191 1500 re2
192.168.8.1 link#3 UHS 0 16384 lo0
192.168.10.0/24 172.16.23.1 UGS 27 1500 ovpnc1
192.168.55.0/24 link#1 U 12244 1500 re0
192.168.55.7 link#1 UHS 0 16384 lo0
192.168.88.0/24 172.16.23.1 UGS 0 1500 ovpnc1
192.168.99.0/24 172.16.23.1 UGS 0 1500 ovpnc1
208.67.220.220 192.168.55.254 UGHS 3 1500 re0
208.67.222.222 192.168.55.254 UGHS 5 1500 re0

The firewall OpenVPN_SERVER rules are of the following servers:

**Rules (Drag to Change Order)
States Protocol Source Port Destination Port Gateway Queue Schedule Description Actions
0/234 KiB         IPv4 *     *           *     * *   * none    **

The firewall LAN rules are of the following servers:
see attached image (lan server firewall.jpg)

The client firewall OpenVPN_CLIENT rules are as follows:

**Rules (Drag to Change Order)
States Protocol Source Port Destination Port Gateway Queue Schedule Description Actions
0/0 B         IPv4 *     *           *     * *   * none    **

The client firewall LAN rules are as follows:
see attached image  (lan client firewall.jpg)

These are the configurations. The problem I have is that the LAN server can not access the LAN client. An idea what might be the solution? Thank you.


[viragomann]

Is the clients side pfSense the default gateway in its LAN?

[ccrr10]

virago mann many thanks for your quick response.
No, the default gateway is the IP of the ADSL router to which the pfSense device is connected. Attach a picture of the setup.


[viragomann]

Yes, but what's about the LAN devices on clients side? Are these configured to use pfSense as theis default gateway?

And you wrote above, you cannot ping from the server to the clients LAN. Did you try the ping from pfSense itself whith source = automatic?
So cannot ping the clients LAN IP 192.168.8.1? And what's about the clients VPN IP 172.16.23.2?

[ccrr10]

@viragomann:

Yes, but what's about the LAN devices on clients side? Are these configured to use pfSense as theis default gateway?

Yes the lan client devices are configured with default gateway 192.168.8.1.

@viragomann:

And you wrote above, you cannot ping from the server to the clients LAN. Did you try the ping from pfSense itself whith source = automatic?
So cannot ping the clients LAN IP 192.168.8.1? And what's about the clients VPN IP 172.16.23.2?

About this table I am attaching two screen shoot. The first is the server ping (no answer) to client gateway, the second is the server ping with success the openvpn client.


[viragomann]

I can't see any reason for that issue in the configuration.

However, I've noticed that the ping responses seem to take a long time and be unstable. One take 200 ms, the other one more than 700, both is very long.
What does the ping between server and client over WAN GW looks like?

For troubleshooting the clients LAN not reachable issue, I would use Packet Capture from Diagnostic menu at pfSense client.

[ccrr10]

Thanks again for your precious help.

@viragomann:

I can't see any reason for that issue in the configuration.

However, I've noticed that the ping responses seem to take a long time and be unstable. One take 200 ms, the other one more than 700, both is very long.
What does the ping between server and client over WAN GW looks like?

up wait time ping depends on the poor quality of ADSL in my area. When ping between server and client by the respective Wan ports have a similar result.

@viragomann:

For troubleshooting the clients LAN not reachable issue, I would use Packet Capture from Diagnostic menu at pfSense client.

I send you attached the screen shoot of the Packet Capture Configuration and outcome.

I also attach the image of the ping that I launched from the server.


[viragomann]

Try to ping another LAN device and take a capture once on OpenVPN interface and once on LAN.

[ccrr10]

These are the results of what you asked for. I hope I have understood what you asked.

attached images.


[viragomann]

Please do the ping also to the LAN device when capturing at OpenVPN interface.

[ccrr10]

I also made the ping of the LAN device and the answer is the "client screenshoot lan capture packet2.jpg". I am attaching again. When ping from openvpn server (192.168.10.1) the LAN device (192.168.8.80) and I capture packets the result is the image I have attached and I am attaching again.


[ccrr10]

I did it again a packet capture of wan interface client.
From openvpn server (192.168.10.1) to the device openvpn client (192.168.8.80).
the result is "image1.jpg".
If in Packet Capture I choose as "LAN" interface does not capture any packets. I'll spare you the blank image. Otherwise, if I want to capture the interface openvpn the result is in the picture that I previously you attached, that is, the "lan capture packet2.jpg" client. I hope I've been sufficiently clear.

[viragomann]

The screenshot above "client lan capture packet4.jpg" in Reply #8 shows a capture of LAN, but there is too much noise at this interface. It would help to select only ICMP protocol.
Also "client lan capture packet2.jpg" from OpenVPN interface only shows pings from the VPN server to the client. Obviously you have activated gateway monitoring on the servers VPN GW. You can it for troubleshooting or enter the destination IP 192.168.8.80 in packet capture at host address to filter for it.

[ccrr10]

Thanks again for your patience.

I performed the following tests:

1. capture of ICMP packets from the LAN interface of the OpenVPN client.
   Ping from openvpn server (192.168.10.1) to device lan openvpn client (192.168.8.80).
   Screenshot "config_lan1.jpg" and "test_lan2.jpg".

2. capture of ICMP packets from WAN interface of the OpenVPN client.
   Ping from openvpn server (192.168.10.1) to device lan openvpn client (192.168.8.80).
   Screenshot "config_wan1.jpg" and "test_wan2.jpg".

3. capture of ICMP packets from OPENVPN  interface of the OpenVPN client.
   Ping from openvpn server (192.168.10.1) to device lan openvpn client (192.168.8.80).
   Screenshot "config_ovpn1.jpg" and "test_ovpn2.jpg".

Yes, I have activated gateway monitoring on the servers VPN GW. Attaching a picture of the setup. "Gateway monitoring.jpg".


[viragomann]

@ccrr10:

Yes, I have activated gateway monitoring on the servers VPN GW. Attaching a picture of the setup. "Gateway monitoring.jpg".

So filtering for the host address 192.168.8.80 in packet capture would supress the display of the monitoring pings.

If there gets nothing to the client it must be a routing issue at server, but all the routes above look well.

[ccrr10]

Dear viragomann, now that the picture of the situation is clearer and we seem to have all the necessary information, I would like to think along with you and to anyone who wants to help me figure out this problem.
When the openvpn server (192.168.10.1) launch a ping to a LAN device openvpn client (192.168.8.80) the Packet Capture set of client interface "openvpn_client" detects the ICMP packet (see "test_ovpn2.jpg"), but if the packet Capture client is set sull'intefaccia "lan" the ICMP packet is not detected, because on the LAN does not reach any ICMP packet.
Now I ask: "What prevents the ICMP package to switch from IP 172.16.23.2 to IP 192.168.8.1 and then to IP 192.168.8.80?".
Now you might think that it is a routing problem or a problem of firewall rules.
If it was a routing issue I wonder: "why, if throwing a ping from the client (192.168.8.1) to the server (192.168.10.1), the packet is either the forward road that return? That is the package arrives at its destination and I have confirmation from the client.
It could be a firewall rule. I think I gave fair rules to forward packets between the VPN and LAN. (see "lan client firewall.jpg")
I make the question again: "what prevents the ICMP packets to arrive at its destination?".
Please do one last effort. Thanks again. Sorry for my bad English.

[viragomann]

@ccrr10:

When the openvpn server (192.168.10.1) launch a ping to a LAN device openvpn client (192.168.8.80) the Packet Capture set of client interface "openvpn_client" detects the ICMP packet (see "test_ovpn2.jpg")

This picture doesn't show the ping to 192.168.8.80, it only shows pings to 172.16.23.2, which is obviously initiated by gateway monitoring, as mentioned above.
To get rid of this, deactivate GW monitoring or filter to the IP 192.168.8.80 in packet capture. Both I've already mentioned.

@ccrr10:

"What prevents the ICMP package to switch from IP 172.16.23.2 to IP 192.168.8.1 and then to IP 192.168.8.80?".

Maybe a filter rule or a false routing. A feasible packet capture of ping requests from server side to a LAN device would bring some light in this, and I've asked for it days ago.
If you can't see the pings on clients OpenVPN interface, test it on the servers OpenVPN interface, but there may be nothing also, so it would be a routing problem.
If you see it on VPN interface, but not on clients LAN, it should be a filter issue at the client.

It could be also a wrong firewall rule on clients OpenVPN interface. So post a sreenshot to verify.

@ccrr10:

If it was a routing issue I wonder: "why, if throwing a ping from the client (192.168.8.1) to the server (192.168.10.1), the packet is either the forward road that return? That is the package arrives at its destination and I have confirmation from the client.

If you do this packet capture with source = automatic, it comes from 172.16.23.2 not from 192.168.8.1. So an routing issue for 192.168.8.0/24 on server side wouldn't matter.
But you may select the source IP manually.

@ccrr10:

It could be a firewall rule. I think I gave fair rules to forward packets between the VPN and LAN. (see "lan client firewall.jpg")

Rules on LAN interface take no effect here, you have to set your rules on OpenVPN interface, cause this is the one where packets come into the client.

@ccrr10:

Thanks again. Sorry for my bad English.

Me as well, please.  ;)

[spyshagg]

I am testing openvpn for the first time myself. I encountered the same situation.  Connection established but no communication.

What I found to be the problem:

In order to make a route work ( me -> server -> client) , the client also needs to have a route back to the origin  (me <- server <- Client).  So I have to push routes to the client letting them reach my server Lans side (big no no).

This is not what i understood from the tutorials.  I understood i would be able to access all vpn clients from the server side, but not have any clients be able to initiate connections to my servers lans.

I expected the client vpn server to know where to find the source ip without having to expose my server lan side to the vpn.

[ccrr10]

viragomann, I deactivate GW monitoring and effectively when the server ping the device on the LAN Client not capture it any ICMP packet whatever the selected interface. I did not understand correctly.

@viragomann:

Maybe a filter rule or a false routing. A feasible packet capture of ping requests from server side to a LAN device would bring some light in this, and I've asked for it days ago.

Excuse me but I did not understand what to do. Because I thought I did. I pinged from vpn server (192.168.10.1) to the LAN client device (192.168.8.80).

I attach screenshot of the client openvpn firewall rule. (openvpn_client_firewall.jpg)

@viragomann:

If you do this packet capture with source = automatic, it comes from 172.16.23.2 not from 192.168.8.1.
….............
But you may select the source IP manually.

In fact, if I choose manually as LAN source I have no results. If I choose I OPENVPN_CLIENT response of ICMP packets from the server.

@viragomann:

…................................
So an routing issue for 192.168.8.0/24 on server side wouldn't matter.
...................................

I do not understand what you mean.

What do you recommend I do?
Thank you.

[viragomann]

@ccrr10:

In fact, if I choose manually as LAN source I have no results. If I choose I OPENVPN_CLIENT response of ICMP packets from the server.

So if this is the case, the only type of firewall rule which could block this is a floating rule on vpn server with the Quick option checked and direction "out" or "any".  Do you have any floating rules there?

If not, the pings are obviously not routed in the VPN on server and I can't see any reason for that.
The only recommendation I can make for this case is to start from scratch. I've read here some posts, where guys had similar issues and didn't get it work. After re-installation of pfSense and set up the same configuration again manually it worked.
Maybe it helps to delete the VPN server and set it up again.