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.

VPN_transfer_network.png
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?

If you use the client export package, you can click the option to export one of the old windows installers with the "-xp" suffix, and you can also check the "legacy client" option in the export package when making inline configurations.

But the best thing to do is ditch XP.

I would try deactivating AES in System>Advanced>Miscellaneous, as the AES instructions are available to OpenSSL natively and don't need additional wrappers to be used.  This is mentioned in other threads.  You might also try using the AES-GCM encryption modes.  Another thing to try is using LZ4 compression and pushing it to all clients.

I  am running with the settings I have mentioned under QEMU/KVM on AMD for remote access with SSL/TLS and User Auth, and for peer to peer tunnels, and it seems to serve me well.

Cheers.

So, bit later than I wanted. But think I've discovered the problem lies with authentication.

May 8 23:21:14 openvpn 65105 Authenticate/Decrypt packet error: packet HMAC authentication failed
May 8 23:21:14 openvpn 65105 TLS Error: incoming packet authentication failed from [AF_INET6]::ffff:(remote site wan):7003 (via ::ffff:(pfsense wan address)%em0)
May 8 23:21:16 openvpn 65105 Authenticate/Decrypt packet error: packet HMAC authentication failed
May 8 23:21:16 openvpn 65105 TLS Error: incoming packet authentication failed from [AF_INET6]::ffff:(remote site wan):7003 (via ::ffff:(pfsense wan address)%em0)
May 8 23:21:20 openvpn 65105 Authenticate/Decrypt packet error: packet HMAC authentication failed
May 8 23:21:20 openvpn 65105 TLS Error: incoming packet authentication failed from [AF_INET6]::ffff:(remote site wan):7003 (via ::ffff:(pfsense wan address)%em0)
May 8 23:21:28 openvpn 65105 Authenticate/Decrypt packet error: packet HMAC authentication failed
May 8 23:21:28 openvpn 65105 TLS Error: incoming packet authentication failed from [AF_INET6]::ffff:(remote site wan):7003 (via ::ffff:(pfsense wan address)%em0)
May 8 23:21:45 openvpn 65105 Authenticate/Decrypt packet error: packet HMAC authentication failed
May 8 23:21:45 openvpn 65105 TLS Error: incoming packet authentication failed from [AF_INET6]::ffff:(remote site wan):7003 (via ::ffff:(pfsense wan address)%em0)

Starts blasting en masse the moment I try to ping/navigate to anything on the LAN. Not sure how to rectify that, given my setup is identical (short of lan address) to how it was setup when it was working for two years.  Google-fu all points to configurations far more advanced than mine on Ubuntu servers or OpenWRT, not sure how to decipher and apply to mine.

Thank you for your advice

i checked the settings and we have no client configuration running on this firewall.
It only acts as a server. and the password policy also only affects spoecific users and not all.

Someone in the AirVPN forums pointed me to

/var/etc/openvpn/client2.conf

to see the configuration pfSense actually generated.  From that, it looks like I can answer at least some of my questions, above:

cipher AES-256-CBC:  It looks like that is generated from the "Encryption Algorithm" menu item and put in the "daemon" area.  Oddly, AirVPN's .ovpn file specifies -CBC, but I specified -GCM.  It works, but that's probably because AirVPN does handle -GCM.  I wonder why their .ovpn specifies CBC instead of anything else?

comp-lzo no:  That's generated by the "Compression" menu item and put in the "client" area.  Since Adaptive seems to give me no problems, I'll stick with that.

dev tun:  This is an interesting one.  It looks like it's sort of generated by the "Device Mode" menu item and stuck right at the top in several ways.  The very first line in the file is:

dev ovpnc2

I can't find anything in the OpenVPN manual about a straight "dev" option other than tun and tap.  I assume it's defining a label for the device ovpnc2 (for OpenVPN Configuration 2, or something).  Then, there's the two lines:

dev-type tun
dev-node /dev/tun2

I believe those are setting the equivalent of "dev tun" for this "ovpnc2" device.

proto udp:  Hmmm.  It looks like this is generated by the "Protocol" menu item and put in the "daemon" area.  But, the option generated is "proto udp4" instead of "proto udp".  I vaguely recall seeing posts around here about udp vs udp4, so I'm going to have to do more research to see if that's correct.  EDIT:  I found a post on the OpenVPN forums talking about using "proto udp4" to work around the problem of "proto udp" trying to set up UDP on both IPv4 and IPv6.  If IPv6 is turned off (which it is on my system), then "proto udp4" is the thing to use.  Odd that they don't list it in the manual page.

remote xxx.xxx.xxx.xxx.yy:  It looks like that's generated by the "Server host or address" and "Server port" menu item and put in the "client" area.

verb 3:  It looks like that's generated by the "Verbosity level" menu item and added right at the top under that "dev ovpnc2" area.

So, unless there's an issue with "proto udp" vs "proto udp4", it looks like I'm OK.

@Gertjan:

Hi,

As said somewhat earlier, it could be this, or, as proposed elsewhere, according Google, you have experiment a bit with "mssfix 1300".

Hi,
thank you for your reply.
I already tried to play with the mssfix, but yet no success.
I also read in another thread, that maybe the time on my machine or the VPN-Server might be out of time - so i changed the NTP Servers, but no success.

Thanks for your reply and sorry for rushing on the issue before properly search.

The rule was not added at all at the first place, however I was able to fix it by adding manually and and correct the udp4 to udp on /tmp/rules.debug file and then running  pfctl -f /tmp/rules.debug
So the firewall won't report the same notice.

Colleague advised "create interface for the PIA VPN" without specifying IP Address, just set the name.
Did that & then adjusted the NAT rules to use PIA interface, & now it's all good.

Nice.
;-)

I manged to resolve the original(!) problem (i.e. openvpn - >pfsense <- ipsec tunnel -> tp-link) by adding a P2 entry declaring the openvn network as local AND (!) on the TP-Link device added a new IPsec Policy (under IPsecVPN/IPsec) using the same IKE Policy as the Tunnel connecting the two LANs.

https://doc.pfsense.org/index.php/OpenVPN_Site_To_Site

So to clarify your asking how to circumvent your schools policy and sneek a vpn connection through?

While there are many ways to do that.. You really should check with your schools policy on such activity - if you have a legit reason to use a vpn from your schools network then they should give details on how to do that.

While you might find some people here willing to help you circumvent.. Many here will not be willing to offer such help.. Good luck.