I was able to resolve it. By making Minute Changes on the VPN CLient Profile. remote <Elastic_IP> 1194 udp //Change WAN IP with elastic IP #verify-x509-name "Netgate VPN Server" name //Comment this Line

@viragomann Looking around and found there is a "reject lease from" option under wan1 interface. I think for some reason when pfsense reboots, upon restarting, it gets the dhcp of 192.168.0.254 from the ATT Modem. I put in "reject lease from" 192.168.0.254... I'll check tonight if this solves the issue. Not sure if the ATT Modem's dhcp is passing out it's own ip address while it's asking upstream ATT server for the actual wan ip address. Maybe someone with ATT can explain why modem's address gets pick up as the wan ip and then later renews to the actual wan ip. Thanks!

@viragomann Thanks from my side as well... I've been struggling with this exact same problem and the firewall rules underneath the OpenVPN tab were the problem for me as well.

@clickerdeveloper From what you described, I assume you have already checked "Redirect gateway" in the OpenVPN server settings and you policy route the LAN traffic to the VPN provider. Hence the VPN gateway might not be your default. So you need also to policy route the OpenVPN clients traffic to the VPN provider. Also you need an outbound NAT rule for the access server VPN tunnel network, if it wasn't added automatically by pfSense.

It is likely that your VPN interface isn't enabled in pfSense. Open Interfaces and select the VPN interface that you added to System > Routing > Gateways and click the Enable box. Click Save. Navigate to Status > OpenVPN and restart the service. It should show a green check mark and show local, virtual, and remote host addresses.

@wedwards Seems like pfSense honours the defaults from OpenVPN >= 2.6. From the documentation: In 2.6 and later the default is changed to AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305 when Chacha20-Poly1305 is available.

@jewilson I made that change to the client specific override and now OpenVPN Connect is allocating 192.168.2.2 to the client and not 192.168.2.0. Thanks for the help.

@rduarteoliveira Thanx for feedback.

@viragomann That fixed it, thanks!

@bingo600 said in OpenVPN - Remote Access User Auth still broken in 2.5.2?: The Gandalf of pfSense ?? hahah - no unless I missed the ceremony myself? ;) The wizard is just a easy way to get a basic remote access vpn up in running in a few clicks. You can always edit the settings how you see fit after. It will even walk you through creating the CA and certs, etc.. Its a great little tool for someone new to setting up a vpn.. Will create the firewall rule for you, etc.

@mikespears said in Unable to access IPSec S2S tunnels over OpenVPN: I just deployed an OpenVPN VPN for client devices, I need them to be able to access the IPSec VTI tunnels I assume, the clients will rather need to access the network behind the IPSec VTI tunnels, right? So the response traffic to the OpenVPN clients has to be routed back on the remote sites. If that is no option, you can do masquerading by outbound NAT on pfSense on the concerned traffic. So this has the same effect for the remote sites as running the OpenVPN inside your network. or would it be best if I run the OpenVPN tunnel on a VM in the primary location, instead of using pfSense for this? Best practice is to run the vpn server on the router.

@maxtheitguy so you want to create a host override wild card? You want to resolve anything.core.microsoft.com to same IP? This is how you would do that via unbound https://docs.netgate.com/pfsense/en/latest/services/dns/wildcards.html#creating-wildcard-records-in-dns-forwarder-resolver You can not do that via gui.. if you want file1.somedomain.tld to resolve to 192.168.1.100, and file2.somedomain.tld to 192.168.1.101, you would have to create the records for those, or point the domain to some other NS that would resolve them to what you want.

@kr0490 got it working, added interface on both for open vpn, and then added some firewall rules, now it’s all good! Thanks for all the help!

@bryanmcdonald25 said in After update boot ask for OpenVPN authentication 3 blue lights sg-3100: had to remove all of the openvpn server The OpenVPN server doesn't use a password when booting. The clients connecting to it could use a password. If you were using the OpenVPN Client on pfSense also, then this was the reason. As it needs (most cases) a password. The correct password is most probably still in your pfSense settings, but, as the OpenVPN client log will tell you, the connection failed. Because you shifted from 2.4.x to OpenVPN 2.5.2 : redo the client settings : consult the OpenVPN serveice you use for details.

@Chris78 Sorry to sort of resurrect this.. I went through all of the instructions , my intent was to have all traffic go through the VPN yet no luck :( Could pfBlockerNG be the cause? I'll admit this is a LOT of steps to go through and so much could go wrong Thank you