OpenVPN clients no longer accessible from LAN after upgrade to pfSense 2.7

reberhar

@lifeboy Hi Lifeboy,

Yes, default goes to the routing tables! You;ve got it. Most of us need policy routing but YOU CANNOT SEND THE OPENVPN queries out to them. So just for the OPENVPN and DMZ, and multiple LAN access you must send those to the system routing table. Only Internet access should go out to policy routing.

If OPENVPN goes there it will be sent out to the Internet as well, where it is lost. The system routing table MUST be used for OPENVPN. That's where all those IP's live that you setup when you configured OPENVPN.

Good job.

What I do is include a simple rule that captures these OPENVPN queries and sends them to the default gateway BEFORE the policy routing rule. If there are a lot of these it is helpful to configure an alias so that don't have to include a rule for everyone of your OPENVPN tunnels or DMZ or Lans that might be impacted by the policy routing rule.

reberhar

This post is deleted!

reberhar

This post is deleted!

reberhar

@michaelschefczyk Hi Michael,

I am still trying to totally understand your system, but no you don't need to remove your policy routing to get your tunnels to work. You just need to make sure that your tunnel access is captured and sent to the system routing tables BEFORE they get to the policy routing rules.

Gosh if I had to remove the policy routing so that I could use tunnels I would be in a real bind. I am busy, but when I have some time I will more closely study your posting.

When you moved to 2.7.0 the system you installed a system that more strictly enforces the the firewall rules. In 2.6 you could still get to the the system table with a policy routing rule. That changed in 2.7.0. Now you must specifically tell the firewall which queries you want to go to the policy routing rules, and which you want to go to the system routing table.

You might want to read some of my responses to Lifeboy.

I hope that helps.

lifeboy

@reberhar It sounds great, except that even if I have one single rule in my LAN firewall rules, one that allows all traffic to go via the default, I can still not reach the client LAN from the server LAN.

For the third time I'm redoing it from scratch now, since @jimp believes that if I follow the instruction exactly (assuming I use my own ip addresses, not the ones in the example), it will work.

Let's see...

reberhar

@lifeboy Gee a total rebuild wow ...

If you are using "any" in your rule as the source, what you are describing will happen. You must use the address of the computer or object or objects your want sent to the default gateway. Then only that device or those devices will go there.

It does work.

Post your firewall rules and I will look at them.

Roy

lifeboy

@reberhar I deleted the OpenVPN server, CSO, client, Certificates, CA, the lot.

Then I started over, created a new CA, added certs (using ECDSA, which we prefer), exported the necessary files, created a new OpenVPN server, CSO and a new client. I added the "allow all rules" into the OpenVPN tabs on the server and the client (actually they were there already), allowed traffic to come in on the WAN (master, since we're using CARP failover) on port 1194 to 1198 (for the different OpenVPN servers) on UDP and (infuriatingly so) it just worked to a point! I can now ping the LAN address of the client from the server (192.168.111.254), but the addresses on other machines I still can't ping.

I know that all the settings where identical to what I had set the previous two times, yet somehow this time it worked better, whereas previously it didn't.

Since I can ping the client LAN address on the firewall, and on the client firewall I can ping the other LAN addresses, why can't I ping the rest of the LAN addresses?
The routes on the server show:

So traffic to 192.168.111.0 goes via 10.0.20.2, which allows me to ping 192.168.111.254 (the LAN addressof the client pfSense)
If I can get there, surely it can't be a routing issue, since the subnet is being routed and I have proven to myself that it's being used.

A packet capture on the client of the ovpn network port shows:

16:24:35.084815 IP 10.0.20.1 > 192.168.111.1: ICMP echo request, id 44900, seq 0, length 64
16:24:36.096403 IP 10.0.20.1 > 192.168.111.1: ICMP echo request, id 44900, seq 1, length 64
16:24:37.109070 IP 10.0.20.1 > 192.168.111.1: ICMP echo request, id 44900, seq 2, length 64

It doesn't seem to be able to get back though like .254 does.

16:26:57.664447 IP 10.0.20.1 > 192.168.111.254: ICMP echo request, id 41430, seq 0, length 64
16:26:57.664537 IP 192.168.111.254 > 10.0.20.1: ICMP echo reply, id 41430, seq 0, length 64
16:26:58.665650 IP 10.0.20.1 > 192.168.111.254: ICMP echo request, id 41430, seq 1, length 64
16:26:58.665664 IP 192.168.111.254 > 10.0.20.1: ICMP echo reply, id 41430, seq 1, length 64
16:26:59.667163 IP 10.0.20.1 > 192.168.111.254: ICMP echo request, id 41430, seq 2, length 64
16:26:59.667212 IP 192.168.111.254 > 10.0.20.1: ICMP echo reply, id 41430, seq 2, length 64

I'm almost there... any thoughts on why not?

lifeboy

Just to add to my reply, the client routing table

Here, the traffic for 192.168.131.0/24 must go to 10.0.20.1, which it does, since I can ping any valid address on the server LAN from the client,

reberhar

@lifeboy Hi Lifeboy,

Try a trace route and see where your queries are going.

If your queries are not reaching the system routing table then it cannot work.

Michael had a similar problem. The trace route revealed it.

Roy

lifeboy

@reberhar I found the problem, and it was not in pfSense!

The LAN client address I was testing with, 192.168.111.1, didn't have a default gateway set yet! I set that and now it's reachable!

Case closed.

The part that I'm still frustrated about is that I'm pretty sure that my setup was correct in the GUI the second time round too, but the problem was not revealed in what was visible. Redoing it fixed the problem, but I didn't learn much in the process.

Thanks for all you effort and input as well!

jimp

Nice that you finally were able to track that down!

We have a nice checklist-style connectivity troubleshooting reference in the docs that may be helpful to keep in mind for the future (and for others finding this thread) which includes that as one of the items to check:

https://docs.netgate.com/pfsense/en/latest/troubleshooting/connectivity.html

More specifically:
https://docs.netgate.com/pfsense/en/latest/troubleshooting/connectivity.html#client-tests

reberhar

@jimp Thanks Jimp,

Of course as a simple outside forum user, I don't always think of the great checklists you all have in the Netgate pfSense documentation. Those have certainly helped me.

reberhar

@lifeboy Hi Lifeboy,

I am so glad you fixed your problem. You are a persistent patient person. The world needs more folks like you.

lifeboy

@jimp Indeed that is a great resource to use for troubleshooting, thanks for sharing it!