@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

@yakatz said in One server out of 5 keeps stopping:

I don't see any mention of it in the logs.

If logging is enabled, where should be any entry in the log though regarding the server went down.
Either in the OpenVPN log if the server was shut down in due form, or in the system log if it crashed.

@mpcjames glad I could help.

@modesty said in Client export - no configurations available:

This "help text" I dont understand what to do...

It says :

If a client is missing from the list it is likely due to a CA mismatch between the OpenVPN server instance and the client certificate, the client certificate does not exist on this firewall, or a user certificate is not associated with a user when local database authentication is enabled.

which means ... what it says.

When a 'client' uses a VPN connection, it should 'authenticate' against the pfSense OpenVPN server, at the connection needs to be secured.
And you have a choice :
A user name and password.
A certificate st, assigned for that user.
Or a combination of both.

You've set up a OpenVPN server, you can see the "access mode" :

b2b463b7-c6ed-4354-9f17-389cf62b20e7-image.png

You have made a choice here :

93502a9d-2fd9-4634-af96-291a397d0474-image.png

If could create a user + password here :

5cc6ee04-8442-4c4e-8520-2a8cbf577233-image.png

and - important, assigned it to the OpenVPN user group, the OpenVPN client export utility can't find a user to include in the export files.

Or create a 'CA' certificate here :

e87f5c2a-ba0f-437c-893a-b88034d5fc47-image.png

I called it "CA-openvpn". As you can see,, it's in use by my OpenVPN server right now.
This CA cert is only created ones.
After that, for each user (do not share certificates among users !!) you create Certificates :

11ba180a-74b8-45c8-be64-5f8c8bee5f53-image.png

This one is for me, for my iPhone. I also created one for my pad, one or two for the PC's I use to remotely access this pfSense OpenVPN server.
Again, this certificate is in use right now by the OpenVPN pfsense server.
Note that this CA certificate is assigned to the OpenVP server :

e5b7de2b-c61b-4ce3-aa04-dcaa31afcb53-image.png

Because I chose :

0104ea83-044d-4ebe-851b-5b723f41fcff-image.png

which means 'only certificates' (and no user or password), I now have this listed on the OpenVPN client export list :

ceaadc91-b136-4008-85d4-afce76204731-image.png

Now, read again :

If a client is missing from the list it is likely due to a CA mismatch between the OpenVPN server instance and the client certificate, the client certificate does not exist on this firewall, or a user certificate is not associated with a user when local database authentication is enabled.

and I'll bet that all is clear now.

and

If you have Youtube installed, go here Youtube > Netgate > Configuring OpenVPN Remote Access in pfSense Software - it's a bare minimum 'need to know' video, but it explains the steps.
Several other, far more detailed OpenVPN videos are also a viable. They are old, but do still apply.
A couple of thousand other pfSense OpenVPN video's also exist.

An there is the manual, in the top right corner, right in front of you, one click away.

@daddygo
Hi

Seem to have this matter resolved.

First, used a Class C private IP address subnet for the VPN client.
Second, the matter with the Android Chrome Browser SSL/TLS was resolved with
revoking the certficate I was using for the WebConfigurator, deleting it and creating
a new one. Only with the new one for the SAN (Subject Alternative Names) I specified the FQDN of the firewall as well as supplying the IP address for the local LAN and the WAN subnet.

Connected without the error message after importing the relevant certs into the Android Cert
Store.

Having checked the OpenVPN logs, I am getting a number of warnings such as;

WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1601', remote='link-mtu 1585
WARNING: 'keysize' is used inconsistently, local='keysize 256', remote='keysize 128'

as well as number of messages stating;

Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #6 / time = (1639703647) 2021-12-17 01:14:07 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

and

TLS Error: incoming packet authentication failed from [AF_INET]92.40.192.240:33082

The VPN link appears to be ok and holds up
I have a concern these may be producing problems. Do you have any insight as to how these
could be mitigated?
As stated, I have tested this on Android mobile and it could be down to link quality with 4G
but I'm not sure.

Any insight as to these?
Thanks for your consideration.
Regards...

@viragomann said in Best practice for site to site, hub and spoke setup:

@bp81
Yeah, you need a configure CSO when you have a site to multiple site setup. This way you tell the server which remote network is behind which client for proper routing.

Took me a while to realize that the vanilla client/server setup specified the remote networks to the server, but doesn't tell the server which gateway in the tunnel network to use for a particular LAN. Obvious in retrospect.

@viragomann
Thanks for your crazy fast reply. It works :)