As I understand it if you enable auth-nocache you will always be prompted for the password when you renegotiate. Else it will enter it for you.

Most people only hit this problem when they use multi-factor authentication because OpenVPN cannot renegotiate because it doesn't have access to the multi-factor.

I would leave it as the default (no auth-nocache) and leave the renegotiation at the default as well.

What details you need? maybe i can provide it for. please thanks

Thanks. I did not specify it because when I installed my first AP, I didn't have to.

Networking is not my area and I learned a lot from you guys here. Installing PfSense forced me to have more hand-on experience on networking.

Thanks John, I didn't realize that. I wonder if he will have to reissue configs for his other users though, or if switching TLS modes is transparent.

@Udbytossen said in Cannot Connect to VPN:

TLS Error: tls-crypt unwrapping failed from [AF_INET]109.57.149.202:1194

Something hitting your box from that 109 address where the TLS didn't auth..

Your IP having a /29 mask doesn't have anything to do with listening on the correct address.

Also not sure why your having your clients source port be 1194?

@baumkuchen

With TAP you have the equivalent of an Ethernet switch or bridge. There's nothing to configure.

I have never set up a TAP adapter on anything, so I can't help with that.

if i remember correctly windows server need tcp and udp 464 to change the password, do you hve it open?

same issue

Most sites cannot be policy routed with a simple DNS Alias because they resolve to many addresses and they load content from many different domain names.

No way adding, say, netflix.com is going to work for you.

appreciate your help/replies. i need to trace back through all that i setup and find where i mis-configured these VPNs and then post back further questions then if warranted. until then ...

Upon further investigation, it seems openvpn calls /usr/local/sbin/openvpn.learn-address.sh specifying the domain, ip, fqdn and an "update" command....
OpenVPN calls this script twice - once for legacy ipv4, and again immediately afterwards for ipv6.

The problem seems to be that this script explicitly tries to create A records irrespective of the value provided for $IP, which when coupled with the ipv6 address are then rejected by the /usr/local/sbin/unbound-checkconf command.

Forcing it to create AAAA records reverses the problem, it now only creates ipv6 records. Given more time i'l look at creating a patch that checks for and creates both.

Does anyone have any idea how to solve this problem?

Probably. I don't pretend to know how FreeBSD handles that but in general, yes. An OS will use the resources it has and try to spread the load over as many cores as it has.