OpenVPN clients no longer accessible from LAN after upgrade to pfSense 2.7
-
@itinfo Ok I see a couple of policy rules. The one at the very top is sending all your OpenVPN queries out to WANGW. You don't want that. It would be wise to move that rule below your OPENVPN rules and see what happens. That policy rule prevents your OpenVPN Quieres from reaching the system routing table.
It seems to me that you may want to change the way you are driving your gateways. If you have only one gateway, you don't need this policy rule. It is literary sending everything out to WANGW. There are better ways to do this.
You may want to put the policy rule that is at the top BELOW the other policy rule with CAMERASGW. I am not sure what the other rules do so you may have to play around to find the place you want it.
-
@reberhar thanks for the insight.
I did see the icmp requests from 10.10.30.19 to 10.10.70.1 being sent out over the WAN interface.
Now they are being sent out over the OpenVPN interface
I removed many of the 'test' rules -much longer story - had an ISP router that went bad and I had to get Netgate/pfSense onboard to prove that it was not my router but theirs. ~ $2,000 of costs
and I now have
Best part of your help is......
It works!!!!!
Thanks a million
-
@itinfo I am glad my help worked. We have all worked frantically into the night hoping, wishing that someone could simply answer our questions and relieve our anxiety and frustration, and that of our users too sometimes.
The switching to 2.7.0 was pariticulary difficult because it broke functioning systems. If you look through the forums here you can see that it was a real struggle for me too. When the light finally went on, I wrote a post that several people found helpful.
At that point some documentation on HA actually helped me understand the problem better too, thus the questions about other Lans and a DMZ. Lan to lan communication can also be broken by policy routing rules.
God bless you,
Roy Eberhardt
-
@Further up your WANGW policy rule is further down in the rules list, but was certainly impacting your tunnel access. I read your rule comments more carefully and understand your system better. Yes you did need to remove this rule WANGW, or insert others that trapped for your tunnel addresses and sent them out to the system routing table.
For me, since I need policy routing, I setup an alias list in a rule that traps my server addresses and sends them to the system routing table. This rule I placed above the policy routing rule.
FYI
-
R rlabaza referenced this topic on
-
@reberhar I'm a little confused by your comments about "policy rules". What are policy rules / policy routing rules or are they just another name for firewall rules that you show in the screen shots you posted?
-
@lifeboy Hi lifeboy,
So normally, when a rule matches conditions in the firewall or a query falls out the bottom the next place it goes is to the system routing table.
If you change that and direct the output somewhere else that is policy based routing.
At near the very bottom of any firewall rule in the advanced area you see something like:
Gateway "HereIsMyGatewayGroup" (quotes mine)
Leave as 'default' to use the system routing table. Or choose a gateway to utilize policy based routing.
Gateway selection is not valid for "IPV4+IPV6" address family.
This is the place you put policy base routing.
Roy
-
@reberhar I can understand if you have multiple gateways that you'd have to add something like this, but I have a single WAN gateway and OpenVPN that connects site-to-site. On the client side I have an LAN rule that allows all traffic. There is only one way for traffic to leave the client and that is via the default gateway.
-
@lifeboy Hi Lifeboy, ...
So does this information help you? Policy routing will break your OpenVPN connections if you're query ends up there. You gotta grab them beforehand and send them to the system table. Then it works.
Roy
-
@reberhar Hi Lifeboy,
I'm sorry that I didn't understand your frustration was coming from your broken VPN. I just answered your question about what policy rules are.
You MUST send any VPN queres to the system table before they reach policy rules or they will fail.
Roy
-
@reberhar Thanks for your patience! I still don't see a way to achieve this, unless the comment below the "gateway" means that if I leave the gateway as default, the traffic will go the routing tables.
Should I not have a rule to manage "all from any" traffic for the LAN then? Or a rule that only allows traffic that's not for OpenVPN?
-
Dear All,
I am very glad that this does get discussed in plain language, now. Please take a look at my situation an point me to the right direction.
My situation is dual WAN with site to site OpenVPN and remote access OpenVPN. Inbound OpenVPN ports are forwarded to localhost, so that OpenVPN is available on both WANs.
My classical LAN firewall rules are:
The problematic "policy routing" is everything where the gatewway colum is different from "*" (also showing the "advanced settings" wheel) - did I understand this correctly?
To not break OpenVPN in pfSense 2.7 I need to remove policy routing from the LAN rules, also correct? From all of them or only those which may end up pointing outbound to the OpenVPN tunnel (please see below)?
Then my take is:
-
The bottom rule "Load balance all other traffic." This will handle traffic going though the site to site OpenVPN tunnel. Should be easy to fix: Normally, I have one of my WANs as the default gateway, but I could just select a gateway group as the default gateway, right?
-
The other rules are more difficult to manage but these will not send traffic to the OpenVPN tunnel - this is where I would need some hints, please - if there need to be changes:
-- The first policy rule is such an example: The VoIP running in the LAN does only work, if traffic goes through a particular WAN (my GW_WAN1). How can I achieve that without "policy routing"?
-- Similarly, I have DSL and CATV modems in front of my pfSense that I would like to reach for admin access (for example rule "Fritzbox WAN2". Of course, I can reach them only through the WAN in front of which they are sitting.
-- Third, my mail server should serve both WANs inbound and outbound - and know which WAN each connection is using. I realize this by assigning source "gateways10DSL" to "GW_WAN1" and source "gateways10CATV" to "GW_WAN2"?
Are those functions still possible with 2.7 using multi-WAN and OpenVPN?
The traffic directed either to GW_WAN1 or GW_WAN2 odes NOT use VPN. Are these policy rules still a problem or is only the "Load balance all other traffic." the issue? Simularly itinfo also redirects to "CAMERASGW" for some destinations. If these rules need to go, the devices in front of pfsense could be put into a different LAN, but binding some output to specific WANs/IP addresses would be challenging.
Regards,
Michael
-
-
@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.
-
This post is deleted! -
This post is deleted! -
@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.
-
@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...
-
@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
-
@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 64It 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 64I'm almost there... any thoughts on why not?
-
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,
-
@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
