can you list providers that have moved to this cipher? i am still using CBC with no issues also this: https://www.netgate.com/blog/more-on-aes-ni.html "AES-GCM in particular has problems with side-channel attacks on pure software implementations. ChaCha20, which nicely avoids these issues when in software, isn’t an option. This is because: a) it’s not RFC-compliant, and b) there are currently no acceleration offloads for it, and the situation is that there could be thousands, or tens of thousands of pfSense instances hitting a single (clustered) instance of our cloud management platform."

Are the network settings correct on the switch? Is the internal pfSense IP the gateway on it? Another reason could be that it blocks access to management interface from addresses outside off its own network segment. If this is the case you can get it working by an SNAT rule on pfSense.

Probably possible but you'd have to write a bunch of php to do it. They are pushing that anyway. Maybe you could configure 5 different clients to connect to 5 different AirVPN nodes.

This thread solved my issue - https://forum.pfsense.org/index.php?topic=147108.0 Added remote site's LANs into Access server's config. Works fine! Thanks!

That is from an issue with the openvpn wizard. Already fixed in 2.4.3_1 and 2.3.5_2

So the client can't reach 8.8.8.8.  :o According to your routing table, it should be routed to your default gateway 192.168.7.254. Try a "tracert 8.8.8.8" to see where it stucks. Maybe it helps to route the DNS server over the vpn. To do so, add "8.8.8.8/32" to you "IPv4 Local networks" in the vpn server settings (comma separated from other networks). Also an outbound NAT rule for the vpn tunnel network on WAN is needed in this case. Maybe it was added automatically by pfSense.

If you upgrade to 2.4.3-p1 that wizard issue has been fixed. So if you use the wizard again after upgrading it will be OK for future tunnels. Editing the current rule and fixing it manually will work around the issue on 2.4.3.

I know saying "me too!" isn't the biggest help ever.  However, I also have run in to this issue. I have my WAN Gateway and running OpenVPN for my other gateway.  At random, my internet kill-switch kicks in because OpenVPN is restarting. May 15 19:25:09 rc.gateway_alarm 98632 >>> Gateway alarm: VPN_WAN_VPNV4 (Addr:REDACTED Alarm:1 RTT:31347ms RTTsd:5964ms Loss:21%) May 15 19:25:09 check_reload_status updating dyndns VPN_WAN_VPNV4 May 15 19:25:09 check_reload_status Restarting ipsec tunnels May 15 19:25:09 check_reload_status Restarting OpenVPN tunnels/interfaces May 15 19:25:09 check_reload_status Reloading filter May 15 19:25:10 php-fpm 243 /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use VPN_WAN_VPNV4. I thought it was a memory issue, I did turn up a few things to push my rig to see what I could get away with but even with things turned down (log retention, number of entries for pfblocker, things like that) it still keeps cycling itself. I will say I only started having this issue in the past few weeks.  I am only running the pfBlocker package, but I do have some large lists.  I initially thought a cron job was causing a memory issue to make this go down however, I switched the cron jobs to once a day at 2am but still experienced the issue. Either of you guys have similar setups that can correlate potential causes so we can start to work towards a solution?  Or smarter minds than my own are definitely in this community so I would love to hear back from someone that can tell me where my dumb mistake lies - I will glady wear egg on my face if it means network gains some stability. Thanks!

From the client: dig @dns_server_ip_address something.com Does that work? If not find out why not.

Sorry. Don't know about all that microsoft crap.

Thanks, it worked! I knew it could be something very simple. I was silly assuming OpenVPN Server pushes the default DNS.

So, I have no idea why it worked, but I installed the VPN version of the client, and it started downloading! I guess the container might be a bit buggy? It's double tunnelled now, so the client makes a VPN connection to the VPN network by using the original VPN tunnels. This stuff makes my head spin!

The OpenVPN tab encompasses all OpenVPN traffic. So any rules there are applied to all OpenVPN connections. The tabs for assigned OpenVPN interfaces (StrongVpnMiami here) have rules only for that connection. So if you want to allow traffic in on only one VPN interface you should put rules there and only there. The main OpenVPN tab is parsed first so if you have an allow all rule there rules on the individual connections are not ever hit. That becomes important if you have site-to-site tunnels with incoming traffic. When traffic comes in via a particular connection you need it to hit a rule on the specific tab so it get a 'reply-to' tag on the firewall state allowing the reply traffic to go back via the correct connection. With a VPN connection to a public server like StrongVPN you normally don't want connections coming in over the VPN at all so don't need rules there. The firewall rules in your screenshot above on LAN have some issues. Nothing can ever hit the bottom two rules because all traffic from the LAN subnet will be caught by the 4th rule and sent via WAN_DHCP. No traffic that isn't from the LAN subnet should come in via the LAN (unless you have routed subnets). Steve

It should look like at the attached drawing. Connect pfSense neither to LAN nor to WAN. The transfer network has to be a separate network. I don't know if your router can provide a third network. If not maybe it's VLAN capable, so you can achieve the same logical setup with VLAN. If you use the WAN interface on pfSense and enter the 10.199.0.1 as gateway, that IP is used as default gateway and packet destined for LAN will be sent to it. So there is no special route necessary on pfSense. Only on the router you have to add a route for the VPN tunnel network. [image: VPN_transfer_network.png] [image: VPN_transfer_network.png_thumb]

Look more closely at the OpenVPN config.  There is a provision to enable netbios over openvpn.  This is easier to do in TAP mode as your OpenVPN clients will already be on the correct network to connect to netbios resources on the OpenVPN server's local network.  If you are using TUN mode, you must allow the TUN network access to the netbios resources you want to connect to.

I just tested this, and was able to hop OpenVPN > PFSense1 > IPSec > PFSense2, but I do use TAP mode which makes the firewall rules on the end points a bit simpler.

What do you mean nobody knows?  Your thread has been here what not even 3 days yet.. If your connecting to a vpn service that is using username and passwords then yes.  If they defaulted to 2, that is just one thing that users would dick up and wonder why it doesn't work because they don't read and just click shit ;) Kind of how there are hidden firewall rules created when you enable dhcpd that are not shown.  Because the typical user would not know what to enable if not there, and if they were shown would end up deleting and then asking why dhcpd is not working. Do you always need to know what they use to make the hotdog? If you want to make it 2 - go right ahead and edit the source file so its a 2.. https://github.com/pfsense/pfsense/search?utf8=%E2%9C%93&q=script-security&type= And update to pfsense will put it back to 3. While openvpn might put a warning in the connection about it… Is it really an issue on your firewall, where YOU created the connection to this vpn?