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

[ccrr10]

I installed another openvpn server no site-to-site but for Windows PC users.
I have the same problems I have highlighted in previous posts.
The configurations are very similar. The difference is that now the openvpn client is a PC with S.O. Windows 7.
From the client can ping the server, which as in the case of site-to-site vpn uses subnet dedicated to her (172.16.24.0/24).
My observation is as if missing a link between the LAN and LAN client openvpn.
My PC has an IP address 192.168.55.14, while the TAP adapter has an IP address 172.16.24.2.
The OpenVPN server has an IP 172.16.24.1 and 192.168.10.1 Gateway.

When my PC ping the gateway (192.168.10.1) the ICMP packet is not part of my LAN but by the IP 172.16.24.2 that is the IP of the TAP adapter. So when I want to ping from gateway (192.168.10.1) to my PC (192.168.55.14), the ICMP packet does not arrive on my LAN but stops the IP of vpn server (172.16.24.1).

I did some tests:

I captured the ICMP packets addressed to vpn server from my PC 192.168.55.14 -> 192.168.10.1

1. Interface LAN does not capture packets.
2. Interface OPENVPN_SERVER_PC (screenshot capture_1.jpg).

I captured the ICMP packets addressed to my PC from vpn server 192.168.10.1 -> 192.168.55.14

1. Interface LAN does not capture packets.
2. Interface OPENVPN_SERVER_PC (screenshot capture_2.jpg).

The routing table of the gateway is as follows. (screenshot Routes.jpg).

In the routing table it can be seen that the route for the 192.168.55.0/24 LAN is through ovpns2 which is on the side 172.16.24.1 server and client172.16.24.2 side.
Now the tests show that the parties ICMP packets from the server (capture_2.jpg) leave from the vpn server 172.16.24.1 and are addressed to my PC 192.168.55.14.

I captured these packets sent from the vpn server destined to my PC with Wireshark interface TAP adapter and it shows how packets do not arrive IP 172.16.24.2. (Wireshark_1.jpg).
Of course the same thing happens if I capture the packets on the LAN interface. (Wireshark_2.jpg).

My question is: "because the ICMP started from vpn server destined to vpn client packages (my PC in this case) stop on the interface of 172.16.24.1 vpn server and are not routed on the other vpn interface. 172.16. 24.2 and then even the IP of 192.168.55.14 PC having the routing table defined the way forward? ".

I attach a screenshot of the routing table of my PC 192.168.55.14 (routes_PC.jpg)

I state that my PC firewall has been disabled.

I attach a screenshot of the LAN and the firewall rules servervpn (firewall_1.jpg) and (firewall_2.jpg)

Thanks to anyone who can help me understand, and special thanks to viragomann that has had great patience with me.

[Derelict]

You are trying to route to other networks on the client side and connect using OpenVPN client on one of the windows hosts there?

Basically a site-to-site connection but using the OpenVPN windows client not OpenVPN on another pfSense?

I don't know if the windows client will do that.

[ccrr10]

Derelict,
thank you for your answer,

@Derelict:

You are trying to route to other networks on the client side and connect using OpenVPN client on one of the windows hosts there?
Basically a site-to-site connection but using the OpenVPN windows client not OpenVPN on another pfSense?

No. I'm trying to understand why after a OpenVPN connection, it is site-to-site or both Windows client userit is not possible (at least for me) to communicate between the two networks: 192.168.10.0/24 LAN and LAN servers 192.168.8.0/24 client (in the case of site-to-site). I posted several screenshots where I highlighted the problem, highlighting the route table and the roles of the firewall. Within these configurations there is (in my opinion) nothing that should hinder communication. I ask the community to pfSense if there is something which I am not aware to run this communication between each network.

[spyshagg]

In advanced configuration "custom options" did you push the routes that the client should reach on your side?

push "route 10.10.20.0 255.255.255.0";

I found the process to fail when using the standard routing fields openvpn profides.  But using custom options it just worked

route  10.0.0.1 255.255.255.0    -> subnet that exists on the client side
push "route 10.10.1.1 255.255.255.0"  -> subnet that existis on my side that the client can reach.

If the client can ping you, then both routes are working I guess. If the forward route and return route didn't exist on either side, the client would never receive the ping response.  Sorry I can't help further.

[Derelict]

Just use Local Networks. No need to mess about with custom options. Look a the generated config. It just pushes the same networks.

[spyshagg]

personally i had no luck with local networks following neither the pfsense book or wikis on google.  Custom options though, worked like snapping my fingers.  route this push that. It was just a thought, but as for the first post description, if he can receive ping requests from one side it implies routes are properly done and something else is missing.

[Derelict]

Firewall rules on either the destination firewall's OpenVPN tab or, more likely, on the destination host itself.

[ccrr10]

Thank you very much for your answers. Thanks for your help.
I also had the impression that it is the firewall rules that prevent communication between the two lan through the vpn connection. I thought I had correctly set the rules, but apparently it does not.

[Derelict]

Post the rules you think were correct and check any local firewall (think windows firewall) on the destination host.

[ccrr10]

What interests me is the OpenVPN connection site-to-site. In fact I attach firewall configurations of both the server (192.168.10.1) that the client (192.168.8.1).