OMG I'm sorry but maybe it'll help someone else in the future. The problem was that the configuration of the VPN Service was set to UDP4 IPv4 and IPv6 an all interfaces (multihome) instead of UDP on IPv4 only Eversince I changed to that setting the tunnel works fine and in the config there was added local 1.2.3.4 which is my CARP IP

Might be a bit late and you probably already fixed it but try and take a peek at firewall -> rules -> openvpn. You do have a rule to actually allow openvpn traffic through the firewall right?

Been discussed in this thread.. https://forum.netgate.com/topic/148713/cve-2019-14899

@JKnott To be really honest... A cosmic thing. Apparently not all VPN servers I've added (as client) are handing out ULA's. So on my dashboard it just looked sh*t. Plus my OCD was hyping over this. ;-) I just want one standard. So all three should give me an ULA or not. Not just one.

Post new screenshots of both the client's routing table when connected and PFsense.

@stephenw10 said in Getting openvpn warnings in the logs: You probably have Enable Negotiable Cryptographic Parameters set Actually not. I disabled it since it seemed to not respect my preference and just use CBC if I remember correctly so I said F it lol I'll live with those warnings. Thank you :)

@JKnott said in Windows client version: but pfSense creates a client for 2.4.8 Which is the current stable version from OpenVPN ;) OpenVPN connect client you refer is a) a beta and b) the client for the commercial RAS Server from OpenVPN Inc. as @Pippin already pointed out. Never tried it though.

Post a network map. Post both the server1.conf and the client1.conf (both located in /var/etc/openvpn)

In order for your roadwarrior clients to access resources @ site B, two things need to happen: Site A's road warrior clients need to know that site B's LAN subnet should be routed down the tunnel Site B needs to know where to send the return traffic for site A's road warrior clients Based on the above, the following adjustments should be made to the configs: Site A: Road Warrior config should have "192.168.20.0/24, 192.168.10.0/24" on the IPv4 Local network(s) line. (Remove 10.0.20.0/24). Site B: Re-verify the site-to-site config has "192.168.20.0/24, 10.0.20.0/24" on the IPv4 Remote network(s) line Once the site-to-site tunnel is re-established and the clients re-connect, you should be good to go.

thanks its a really good reply, but i fear my only option is to change the gateway of service.domain.com I already have an internal DNS and that is part of the problem, because that points to a lan host with a different gateway. i need this DNS for other services. LAN clients gets DNS server from DHCP and openvpn clients gets it from openvpn server. i can se that DNS resolver is enabled in pfsense (its on per default) maybe i can do some magic here. what if i make a Host Override in resolver and in openvpnserver sets pfsense as primary DNS and the internal as secondary. service.domain.com is a mailserver so i dont wants to screw anything up here.

What do you want to disconnect on? If less then X bytes in Y seconds.. Or just leave off bytes and put in how many seconds of idle (no traffic) and then will be disconnected.. If you wanted to disconnect after an hour it would be 3600

Sad to report back that a switch to OpenWRT/mwan3/WireGuard did the trick. pfSense needs WireGuard bad AF :|

@viragomann I have now tried 2 different certs ( both server and client use the same in each instance ) and she still does not show up in Client Export - my own was an existing entry in CE and I can now see the target network - incidentally, I only have one server in the dropdown for Remote Access Server in CE - ok I just reran the wizard to wetup the other server (duh!) and she shows up under the new server; however she cannot see the remote network - I have made a few adjustments - will update tomorrow when I know more UPDATE: She's in! I needed to make a new cert for her that matched 100% - sorry, this was very confusing to me. Thank you, everyone for your insight and assistance!!

Possibly the Windows host firewall is blocking the access.

@seejay said in OpenVPN TAP pfSense Gateway Website Inaccessible: Ultimately no matter which TAP/bridging configuration I've employed for site-to-site TAP I have odd issues like the one outlined in this post, or random packet loss and/or TCP resets. You've seen me go through things like the MTU and other diagnosis ad nauseum to no avail. One thing you'll have to bear in mind is the bandwidth mismatch between the VPN and LANs. The LANs can handle data a lot faster than the VPNs. So, if you're bridging the LANs, as you do with TAP, then there's no way the VPN can pass all the data between them. In my case, the LAN is Gb, but my Internet connection runs at about 91 Mb down and 11 up. That's a ratio of over 10:1 in one direction and almost 100:1 in the other. This is before we even can consider the limitations at the other end.

@CM350 Changing from UDP to TCP also worked for me. Same port is fine. But I think the ISP may have been have been having issues with UDP.

Thank you for the reply, that did the trick i rebooted and it started to work flawless Thank you again for all the help