For anyone who might be interested (after running into the OpenVPN issues i experienced with multiple customer after upgrading both our customers and our own pfSense boxes to 2.5.0:
All the OpenVPN related issues dissappeared "like snow in the sun" after upgrading to 2.5.1 !!
(So, @bennyc i think we can agree that there was an issue... ;) )

However.... a big advice to those who have multiple WAN-connections (wether or not using load-balancing or fail-over mechanism's...) before upgrading to 2.5.1: do not upgrade!!!
Those customers we have with multiple WAN's had serious connectivity-issues (not only over VPN but also from/to the internet) after upgrading from 2.5.0 to 2.5.1!

Rightnow i don't have the time (or desire) to look into this new introduced issue in 2.5.1... i'll just wait for the next patch or major update and have another go with upgrading a multi-WAN customer....

Cheers.

Fixed by creating another LDAP auth server and entering the same config as before ...

I will diff that in detail, for now: works!

@dannyr1992 We have managed to get the Firewalls to communicate. Turns out it was compressions settings which is madness.

Even thought the firewalls are communicating and the routing table is correct the LANS cannot communicate with each other.

Does anyone have any ideas

Does anyone else face this issue, or has an idea where to start solving this issue?

@viragomann Thanks a lot :)

@zabi

Hi,

my output,

[2.5.1-RELEASE][admin@pfSense.home.arpa]/root: grep scrub /tmp/rules.debug scrub on $WAN inet all fragment reassemble scrub on $WAN inet6 all fragment reassemble [2.5.1-RELEASE][admin@pfSense.home.arpa]/root: grep vpn_networks /tmp/rules.debug table <vpn_networks> { 192.168.77.0/24 }

My connection to RDP after authentication to Windows, the screen blank..
After that my ping will be timed out..
If i close my RDP Windows, the connection will be back after 30 seconds..
I can access to HTTPS, HTTP, SSH without any issues..

Just wonder is it the version 2.5.1 bugs..
I will deploy version 2.5.0 to try it out again..

@divsys You were right. I was missing the Client Specific Override entry.

I created a CSO on the server side, selecting the correct OpenVPN server,
with the Common Name from the client certificate certificate,
my IPv4 Tunnel Network set to 10.0.9.0/24
my IPv4 Local Network/s set to 192.168.1.0/24
my IPv4 Remote Network/s set to 192.168.10.0/24
and my routing fired right up.

You are the man.

@peterzy It seems that the pre release "2.6.0"corrects the Mult iWAN bug.
See the forum post related to that issue.

@gertjan Yes to all. On latest version of PfSense, client export package. For the client, I use Passpartout as it automatically turns OpenVPN off when in range of trusted WiFi...like arriving at home or the office. OpenVPN Connect really needs to add that feature.

I might give OpenVPN Connect a try to see if any different.

nevermind, found the issue. i had specified an IP address reservation for the pfsense firewall on the openvpn server, and had the subnet wrong. it was set to the vpn tunnel gateway, instead of 255.255.255.0, so pfsense had some issues with it. changed appropriately and it works now... RTFM.....

Had same issue. Unticked: "Provide a DNS server list to clients. Addresses may be IPv4 or IPv6."

Fixed :)

After playing around, I can assign the .40 tunnel, but can't assign the same IP that I normally reserve for my phone on that subnet or I get no internet service. I get randomly assigned IP of .40.2. That IP has no hostname in the Pihole query list and does not show up in the DHCP status so I can assign a static IP and give it a hostname.

I'm at a loss how to assign a hostname. I know it's trivial, but if I was running it with several hundred VPN users, I would think there's a way to assign hostnames when they log on. I've googled and searched, and I can't find how.

Thanks for any help.

@vincent_28
The reason might be a missing route on the client.

To direct internet traffic over the vpn, check "Redirect gateway" in the server settings.
Also ensure that pfSense has added an outbound NAT rule for the OpenVPN tunnel network. In the picture there might be a typo in the vpn network, the shown is a public IP.

@vincent_28 said in Destination Network:

I already setup also in rules > OpenVPN> the destination is WAN Net but not still appearing the IP of WAN.

This does not allow internet access. WAN net is only the subnet of your WAN IP. So if it's a /32 (PPP), there is nothing else included.
You need to set the destination to "any" in the pass rule. If you want to prohibit access to your LAN add an additional block rule for that destination to the top of the rule set.

Still and issue on SG-3100 running 2.4.5-p1:

cipher_ctx_update: EVP_CipherUpdate() failed
Exiting due to fatal error

Nobody can connect, service crashes and continue crashing after restarting.
The only solution seems to be a full firewall reboot.

This sounds like it's a bug in OpenSSL: http://cve.circl.lu/cve/CVE-2021-23840

On our SG-3100 we have 1.0.2u, which is affected. Changelog says it was fixed in 1.1.1j in Feb 2021: https://www.openssl.org/news/changelog.html

Is the fix likely to ever find its way to 2.4.x or was 2.4.5-p1 the final release?

Strange, since I've completed this setup :

adding the outbound NAT for the VPN creating the gateway add a dynamic dns entry for the VPN "wan" interface

some process or something kicked in, because now I get a mail every 15 minutes with in the subject :

Arpwatch Notification : Cron <root@aureliusgate01> /etc/rc.filter_configure_sync

and the following content in the mail body :

X-Cron-Env: <SHELL=/bin/sh> X-Cron-Env: <PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin> X-Cron-Env: <HOME=/root> X-Cron-Env: <LOGNAME=root> X-Cron-Env: <USER=root> 0 addresses deleted. 0 addresses deleted.

I know this is the cron line with the schedule

0,15,30,45 * * * * root /etc/rc.filter_configure_sync

but I didn't add it or activate it, so it was there already, so I wonder why it now is "active" or sending these mails?

Thank you very much

Now It´s working fine.

@nunu thanks for helping me on this.

When I look at the routing table on windows (route print), I see the route, it looks like it is setup properly

I wonder if this is a ipv4/6 issue.

@preimmortal said in OpenVPN Server Behind NAT being blocked by Firewall Rule:

I checked the firewall log to see why this is occuring:
Apr 21 16:29:11 ► CLIENT_VPN Default deny rule IPv4 (1000000104) 192.168.0.100:1194 123.123.123.123:12345 TCP:FPA
In this case, 192.168.0.100:1194 would be the WAN address for my pfsense box and 123.123.123.123:12345 would be the client trying to access the VPN. The CLIENT_VPN is a client VPN connection that is being used for other outbound traffic. I would have expected the OpenVPN Server to use the default gateway, which is WAN

Basically respond packets are routed accordingly to the routing table if the incoming interface of the requests is unclear.
I suspect that the other client connection set the default route, presumably pushed by the server.

I reviewed my firewall rules and tried to set up some rules to force all outbound traffic to use the WAN gateway and also set up the Outbound NAT for the OpenVPN Server:

Outbound NAT rules have no affect on respond packets.

I tried to set up policy based routing documented here:

Not clear what you aim to achieve with that in this case.

Simply ensure that there is a firewall rule on the WAN interface allowing the OpenVPN access on port 1194, ensure that there is no floating rule or interface group rule matching this traffic.

@gertjan pfSense 2.5.2 is due anyways. 😁

@kakerstrom Interesting, I recently set up a Hurricane Electric IPv6 tunnel which involves adding an interface. I was already connected to the web GUI via a PC on LAN. Routing out from the PC over IPv6 actually worked but I found I couldn't ping or DNS query the new LAN IPv6 until I restarted the router. Firewall rules seemed to be ignored as the default block rule was triggering. Sounds like you restarted after removing the interface? Would have been interesting to know if restarting first would have fixed it for you...

For client/remote routers we usually allow GUI and/or SSH access from our IP, either on WAN or if they have a web server one can NAT forward WANIP:50443->LANIP:443 (still limited by source IP). Also re: referrers, in System/Advanced/Admin Access, set "Alternate Hostnames," for instance add the WAN IP or hostnames.

I have the similar issue after upgrading to 21.02.2 version on my Negate SG-5100. Prior to upgrade all OpenVPN connections were working fine. After upgrade only one VPN connection is working, other is connected but no traffic passing. On disabling the VPN on connection 2, data traffic starts but not on VPN.

Not sure if it's a bug generated by pfsense update.

@sakthi said in Not able to RDP or SSH via OpenVPN:

and i'm able to access the ESXi homepage as well

What is the IP of this ESXI VM ? 192.168.65.x/24 ?
pfSense is 192.168.65.1 ?

During setup, set up firewall rules on the OpenVPN (or OPENVPN interface if you have instantiated the OpenVPN interface - see Youtube => Netgate video's for details) lie this :

d891ffed-7b91-45b7-a625-eae293eb9346-image.png

I'm using myself the OpenVPN server of pfSense so I can call in, use the GUI of pfSEnse, or the SSH access, and also some RDP access to other devices on my LAN's (192.168.1.x/24 and 192.168.2.x/24)
My OpenVPN Tunnel network is 192.168.3.x/24

I had to inform my RDP (Microsoft based devices) that these had to accepts connection from the outside of their 'own' LAN, as by default they are restricted to their LAN == local access only.

Btw : I have two local physical networks, 192.168.1.x/24 and 192.168.2.x/24
As my devices to be contacted from "remote" are all on 192.168.1.x/24, I used the 192.168.2.x/24 network to see if I could connect to these RDP and SSH devices on 192.168.1.x/24.
When I knew how to make it work from 192.168.2.x/24 I knew I could also make it work from 192.168.3.x/24 - the OpenVPN network.
That was the moment I started to build my OpenVPN access.

@mgiammarco2
I have deleted carp/nat/gateways/gateways groups on slave
XMLRPC recreated them again but again wrong.
How can I file a bug?

@johnnyfive Yeah this is the problem - what a shame. It would be really great to have full acceleration using QuickAssist!

@notahacker
The policy routing rule directs any matching traffic to the VPN server.
So this will also include DNS, however, your computer might been configured to use the PiHole for name resolution.

So if you want to use your PiHole on this machine you have to add an additional firewall rule without a stated gateway above of the policy routing to allow the DNS access.
However, this will result in DNS leaks, cause with this the DNS goes out the WAN interface.
You can only avoid DNS leaks by directing DNS requests from the concerned computer over the VPN.

@airwave said in Upgrade to 21.02 -> Client Cert on LDAP server no Longer Accepted:

I updated to 2.5.1 AND now it works and a connection is established and traffic is been delivered, but ONLY ONCE after openvpn service start.
When I then disconnect and reconnect, again I get a connection, but the communication / traffic (ping etc.) is not working. Only in the first connection traffic works. When I restart the openvpn service then, its again working once...

Hi all,

I tested a bit deeper and found out, that the attribute "explicit-exit-notify" in the openvpn client configuration seems to remove my issue with "no communication on reconnect".

So then I guess this problem is fixed with 2.5.1 and explicit-exit-notify.

Cheers

@stellir said in OpenVPN is setup and connecting but no access to local shares.:

@viragomann said in OpenVPN is setup and connecting but no access to local shares.:

add a pass rule to the Windows firewall for the VPN tunnel network

Any direction to accomplish this would be appreciated. The wizard created a Pass rule for the OpenVPN on port 1194 so what else is needed.

You need to do the on your Windows 10. This one:

Ok I disabled the firewall on the Windows 10 computer hosting the files

That's not the topic of this forum and I'm not sitting on a Windows currently. But there is an option to add firewall rules to it, something like "firewall advanced settings". Add an allow rule for the source of the VPN tunnel network, maybe you want restrict ports or simply allow any.

@viragomann Thanks for your help, sir! I really appreciate it. I am unsure as to how or why, but changing the connection to UDP seems to have fixed it. I don't know why or whether this alone was the issue, but the rules are the same and it now just works. It has also been re-booted a few times.

All the best, Richard.