P2P VPN server can't reach client, but client can reach server
-
UPDATE: I got my configuration working. Found the answer in this post. I had one of these 'policy rules' that @reberhar pointed out, on my LAN firewall sending traffic out the WAN. I pinged the remote side, this time packet capturing on the WAN interface (wish I would have thought of that a few days ago), and sure enough the echo requests were going out the WAN, not to the VPN. Deleted that rule and its all good.
-
@rlabaza I carefully studied that post and the fix and it's clear as mud to me :-)
I have one rule for the LAN and that is to allow all traffic to anywhere. How can that route the traffic to the wrong destination to bypass the routing table?
-
I eventually found this:
https://docs.netgate.com/pfsense/en/latest/multiwan/policy-route.html
So from the LAN one should point the OpenVPN traffic not via the default gateway if I get the jist of what @reberhar has to say in your referenced post. However, under the advanced section on my very simple setup, there is no option to select any other gateway. I have only 2 LAN rules, the anti-lockout one and the "all traffic" rule.
-
@lifeboy Does your "LAN subnets" alias on the "all traffic" rule include the tunnel network? Try setting the source to 'any' and see what happens. The packet captures are what really cleared things up for me--watching where the ping requests were going on the different interfaces LAN, TUN, WAN. They have to be going somewhere. I read that post 3 times and it never clicked. The fourth time it finally did...that prompted me to packet capture the WAN ans sure enough that's were they were. My setup is simple as well, IDK where I got that policy rule--probably trying different things at 1 AM over several days. Once I removed it, the system took care of handling the routing of those pings not to the WAN, but to the TUN.
-
@jimp, since my bug report was closed, I can't comment there anymore, but this seems to be a documentation bug at the minimum. If there was a significant change in the way rules work in 2.7.0, then there should be updated documentation on how to set up an OpenVPN site-to-site connection. As it stands now, following the instruction does not result in a working site-to-site connection.
-
@rlabaza I watched pings come in on as below (from the server ovpn ip to the client ovpn ip. They seem to be arriving fine.
16:24:52.961958 IP 10.0.20.1 > 10.0.20.2: ICMP echo request, id 19195, seq 0, length 64
16:24:53.052314 IP 10.0.20.1 > 10.0.20.2: ICMP echo request, id 33787, seq 0, length 64
16:24:53.972680 IP 10.0.20.1 > 10.0.20.2: ICMP echo request, id 19195, seq 1, length 64I assume that the issue is that the response is not routed correctly back to the server as per the routing tables, but how does one do that with a policy rule?
-
@rlabaza On the client I have added a rule to direct the OpenVPN ip addresses before the general "allow all rule", although it doesn't make sense to me. The "allow all rule" should take care of the OpenVPN addresses as well and send them to the default gateway?
What I don't get is that I have another point-to-point service to a different pfSense box, which is also site-to-site. It runs pfSense 2.6 and traffic between the server and client flows without any issues.
What obscure change was made to 2.7 that breaks the comms to the client without this mystery rule and why is not clearly stated in the documentation somewhere? Or am I just not able to find it?
-
My LAN rules:
Detail of the "OpenVPN_ips" rule:
I can only select default or WAN. Default is what the next rule "Allow to any" uses as well.
?
-
So now I have disabled all LAN rules, except the one that sends all LAN subnet traffic to the default gateway.
However, I still can't reach the client side LAN addresses from the server's side.
-
Please read and follow this exactly and do not skip any part of it no matter what:
https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-s2s-tls.html
I just followed it word for word yet again for one client/one server and it resulted in a working LAN-to-LAN VPN as it has the last several times I tried it. Nothing changed here in the last several years.
You must have a Client-Specific Override even for one client. The override sets up the internal routing in OpenVPN that tells OpenVPN which client should receive traffic for a given subnet. It does not matter how many clients are on the VPN when setup this way, this is still a required step.
Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!
Need help fast? Netgate Global Support!
Do not Chat/PM for help!
-
@lifeboy When I pinged the client side from the server side pfSense box, everything worked fine. But when I pinged from a server-side machine, it would not get to the VPN. Have you tried setting the source in your rule to "*" and not "LAN subnets" alias?
-
@jimp I will redo it again and follow the instructions step by step. After all, it's not a production environment yet unless I can get this thing to actually work.
-
@jimp We use ECDSA certificates instead of RSA. That would not break the routing of traffic from the server LAN to the client LAN, would it?
I'm redoing the tunnel and it connects fine, which to me means the certificates are ok.
-
Please see my reply and the resolution at https://forum.netgate.com/post/1151441.
Thanks to all for the massive effort!
-
@lifeboy Glad you're working now. What I learned on my journey to solve this problem is that there are many different causes that manifest in the same failure signature. The story of my (professional career) life. We were always the lightning rod.
