OpenVPN clients no longer accessible from LAN after upgrade to pfSense 2.7
-
This post is deleted! -
@michaelschefczyk The cause was exactly what @reberhar has just explained. To prevent LAN devices from crossing to other subnets, I had put WAN as gateway to the allow rules. In 2.6 access from LAN to vpn clients managed to get thru this rule. But in 2.7, I need a rule with default gateway to let the LAN to VPN traffic to get thru.
-
@reberhar see my case:
My Pfsense have two VLAN more one tunnel site-to-site OpenVPN to comunnication only with VLAN20.
This configuration is:
LAN firewall: 10.1.1.1/24
VLAN10: 192.168.15.0/24
VLAN20: 172.24.0.0/24LAN client firewall: 10.0.0.0/24
IPv4 Tunnel Network: 192.168.210.0/30
Communication LAN - VLAN10 is blocked.
Communication LAN - VLAN20 is blocked.
Communication VLAN10 - VLAN20 is blocked.But, LAN and VLAN10 is possible ping all LAN client: 10.0.0.0/24
I can't identify why the firewall is routing the other side of the tunnel to an IP range that is not included in the OpenVPN settings.
-
@patrick-pesegodinski Hello Patrick,
It sound like you are having a frustrating time.
With the information you have given it is difficult to understand exactly what your problem is. I can make a few suggestions and ask some questions.
Please be more specific in your description of the problem, including when it started and also the version of pfSense you are using. What are the firewall rules involved in this problem? What is the mask that you have for each of these address?
Is this access available in a similar manner other than ICMP - ping, on the other protocols, TLS, UDP etc? How have you configured your clients and your servers? How and why did your block access across these lans?
From one of my servers, a piece of client configuration.
IPV4 Remote Servers 10.3.0.0/21,10.0.0.0/23,10.1.0.0/22,10.2.0.0/21
This is an important line and might hold the key to what your problem is. You should only include the servers in this line that you want to talk to each other.
I work in Spanish and English and I know that when I write in Spanish that I have to err on the side of providing more detail for my friends and coworkers to understand.
-
I'm having a very similar problem after upgrading from Pfsense 23.05 to 23.09
I have a policy based route that directs traffic from specific source LAN IPs over an OpenVPN client connection. The VPN host is a generic privacy service (Privado), and its IP is dynamic.
The rule is triggering - I can see the byte counts going up, but pings through it from hosts have no connectivity.
If I ssh into PFsense, I can ping from the interface (ping -s vpnclientip 8.8.8.8) and I can see replies over that interface just fine, so it's not an issue with the client settings.I rolled back to 23.05 and all is well again, but i would like to understand how to fix it.
-
@djrobx I use the community addition, but I know that the route to Open VPN is through the system routing table, not with a policy rule. The policy rule will prevent your quieres from getting to open VPN.
From my post above
So your gateway group or other gateway is a policy based routing.
Ok again, really cool... but also read what it say... "Leave as 'default' to use the system routing table."
When you do a policy routing like this whatever matches the rule uses that policy routing ... and it NEVER gets to the system routing table which contains the information for your tunnels. So your request goes to the gateway group or other gateway or gateways your have chosen, and they say, "HUH?" and probably sends it out ...
I hope this helps
-
I found the cause of my issue but I don't totally understand it.
I have two OpenVPN clients - one to the privacy service (PrivadoVPN) and another "site to site" client connection to another friend's PFSense router that I open and create rules for only when necessary. That second client is disabled at the moment, but its outbound NAT rule still existed.
If I move the Privado NAT rule ahead of the private client NAT rule, my policy-based route starts working. So somehow the inactive client is interfering with the policy route function in the newer PFSense where it didn't before.
-
@djrobx The new release of pfsense does strictly enforce the firewall rules where the earlier version did not. Your action makes perfect sense.
-
@reberhar The policy based rule was preventing your Private NAT rule from reaching the system table.
-
@reberhar
To all, I have this same situation and I am using the System tables, however the Routes set up within the system tables are using the same IP address as the default gateway for each Point-2-Point VPN connection: 10.0.4.2Common Name: Remote sites IP DG in the <Diagnostics-IPV4 Routes>
P2P_Maine 10.10.60.0/24 10.0.4.2
P2P_NH 10.10.70.0/24 10.0.4.2
P2P_DBS 192.168.11.0/24 10.0.4.2
In the server configuration: VPN/OpenVPN/Server
IPV4 Tunnel Network: 10.0.4.0/24
IPV4 Local Networks(s) 10.10.30.0/24, 192.168.11.0/24, 10.10.60.0/24, 10.10.70.0/24
IPv4 Remote network(s) 192.168.11.0/24, 10.10.60.0/24, 10.10.70.0/24
Gateway creation: IPv4 onlyunder Status/OpenVPN
Common Name Virtual Address
P2P_Maine 10.0.4.3
P2P_NH 10.0.4.2
P2P_DBS 10.0.4.4The hose: 10.10.30.16 has a virtual address on the VPN interface of 10.0.4.1
The problem I have is the same as discussed, I cannot connect to any device on the client sites.
I have read the TLS configuration and many documents regarding the settings and cannot find any inconsistencies.
This worked pre-2.7.1Looking for any assistance to identify if this is the same issue as above or completely different.
Thanks in advance.
-
@itinfo Hi itinfo,
So I am trying to wrap my mind around all that you have said here. First do you have any policy routings at all? You were running a pre 2.7.1 version of pfSense and upgraded to 2.7.1 right? Were you running 2.7.0? Do you have Suricata or Snort or pfBlocker? Are you getting any error messages or do your attempts just time out? What are the logs telling you? Have you tried a trace route to see where the system thinks it is going? What does ping do? What about your output wan that is sending out and receiving the queres? Has that changed? I recently changed my Internet facing wan and had some configuration to cover that. It does not seem like that is your problem however. Do you have a DMZ? How many lans do you have?
2.7.0 began to strickly enforcing firewall rules, That was why the work around is needed for anyone who was using policy routing rules., but if you were already running 2.7.0 without your OpenVPN problems, then the problem is elsewhere.
One of the problems I had in upgrading to 2.7.1 was that Suricata began to block some of my IPs. There have been several Suricata updates since then.
How far are you getting? Are you able to look at the pfSense gui on the other side?
-
To answer your questions.
I was running 2.7.0 with the same issue.
pfBlockerNG came with the upgrade - so yes running it.
Here are my static routes:
Here are my Firewall rules:
WAN:
LAN
OpenVPN
OPenVPN Server config
<Status-OpenVPN>
-
@itinfo
more:Note 3 VLANS have the same gateway - yet above in the <status-OpenVPN) we can see for instance P2P_Maine has a target network of 10.0.4.3 for VLAN address of 10.10.60.0-/24
Here we can see that the route to 10.10.60.0/24 has a default gateway of 10.0.4.2 (this is the endpoint of P2P_NH above)
<Diagnostics-Routes>
Here is tracert to 10.10.60.254 (Netgate router on Vlan 10.10.60.0\254)
from 10.10.30.19
Here is a package capture on the LAN interface for a TraceRT from 10.10.30.19 to 10.10.60.254
no response
here is an RDP request to a workstation 10.10.60.151
No packages on the WAN interface from or to 10.10.30.19 nor 10.10.60.151
Seeing traffice on the WAN to the IP 10.10.60.151 tracing Port 3389
However I don't know what the destination (gateway) that the packages are looking for
Traffic on the VPN interface (OVPNS6) from the 10.10.60.x/24 network, but nothing to the network when trying to RDP to 10.10.60.151
The site: 10.10.60.x/24 has a gateway on the VPN of 10.0.4.1 (the Server side of the Tunnel) thus their traffic is flowing.
When trying to connect from the server side (10.10.30.19) to 10.10.60.151 there is no traffic on the VPN interface (OVPNS6)
So, with all this I welcome your insight.
-
@itinfo What was the version of pfSense you upgraded from? Do you have any policy routing rules?
I am not with Netgate so I am trying to think this through when I have a chance. I have 8 pfSense servers plus other servers behind them that I maintain.
Look carefully at you Lan firewall rules. From what I see and what you are telling me, that is the first place to look.
-
-
@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?
