Hi, Because of the differences, is it still a question for me which pfSense version is this? (for example, it's a difference...) The second important thing is server mode (you use TLS), but that's all I see: instead of: I don't see your own cert for the connection either: instead of: like: and even a VPN User is required: with: exactly where does the DNS (10.0.1.31) point?? this is the box itself or a separate DNS server on the network

You have to forward OpenVPN packets on your ISP router to the pfSense WAN IP. The pfSenes WAN address should be static. Configuring an OpenVPN Remote Access Server If your public IP from your ISP isn't static, you will have to use a dynamic DNS service to have a static FQDN, which you are able to connect to from outside. The DDNS update should be done by the ISP router if possible. If it doesn't support that you may do it on pfSense, you can run a cron job with a short interval for that.

@careymichael I am having this same issue. When you said you had a static route pointed to the LAN interface, are you meaning in the firewall rules?

So uh... I totally disabled the VPN in order to be able to actually upload anything. Screenshot fail! Should be a little more enlightening here...

Got it! Thanks so much for your help. I've changed a dozen settings in the last couple of days so it's hard for me to say exactly what did it. The last thing I did before it started working was actually to uncheck the box that says "Force all client-generated IPv4 traffic through the tunnel." And now when I go back in, it shows checked again... hmmm. In any case, it's working now and I hopefully won't ever have to do any troubleshooting ;) Thank you again for taking the time to help me.

Gertjan, Thank you, I changed it to 192.168.9.0/24 and now things appear to be working!! I'd tried that at one point but when I did the OpenVPN service wouldn't start for some reason, the log said something about a subnet mismatch (don't have log anymore) and I couldn't connect at all, when I brought it in to 192.168.0.0 the service would run. Not sure what the problem was before but it's working now. Thanks again!

@gcu_greyarea Ok danke schon mal für die Ausführliche Beschreibung der Möglichkeiten. Das muss ich mal testen mit einer Failover Group (noch nie was mit gemacht) , kann man denn nur eine machen? 2 .Das kann man natürlich machen dann kann man halt einer gewissen Gruppe eine feste IP zuweißen, und wenn sich der Tunnel neu aufbaut gibt's halt ne neue Exit IP für alle innerhalb des Alias. Das ließt sich so das man für eine vorgegebene Zeit einem Gateway zugeornet ist und der dann ein Zwangs Wechsel durchführt. Das werde ich mal testen was der daraus macht bei ein paar IP check Seiten.

You need to push the IPv6 /64 as a route. It needs to be distinct from the tunnel network. I assume you have more than a /64 to use? /48 or /56? Similar to how HE's TunnelBroker provides IPs, Unfortunately TunnelBroker does not work in this case because they Block CloudFlare (YES THEY FREAKING BLOCK CLOUDFLARE!!!). Based on my experiences with HE over the years, if they did in fact block these sources, they have a good reason for doing so.

In case this will help any one else, I've figured this out.... Here is a link on how to find the logs for NPS... https://social.technet.microsoft.com/Forums/windows/en-US/45aa3000-c32b-483b-8d6e-565b56b163fc/how-to-check-the-nps-logs-in-the-event-viewer?forum=winserverNAP Basically there are text file logs in c:\Windows\System32\LogFiles\In* , or you can check in Event Viewer under Diagnostics -> Event Viewer -> Custom Views -> Server Roles -> Network Policy. In my case, the problem users were set to "Deny Access" under the "Dial In" tab of the user properties in AD Users & Computers. Setting to Allow Access fixed it up. If you don't see the "Dial In" tab, this may be of help : https://support.microsoft.com/en-ca/help/975448/the-dial-in-tab-is-not-available-in-the-active-directory-users-and-com For me, I had to be on the server to get that tab, not accessing Active Directory Users and Computers on another PC. Hope this will help someone else. Thanks, Derelict for pointing me in the right direction!

СА на сервере - ВПН сервера (с 1195 портом это тот который сейчас нормально работает на старом пфенсе а с 1190 тот который не могу завести Клиент на новом пфенсе

Ok, final update. Eliminated everything that had to do with this VPN, interface, rules, etc. Started all over, following all the steps, and everything is working as it should, without the manual routes. By the way, if you run into the routing problem, you can change the "Gateway creation" to BOTH or to IPv4 ONLY and apply/save ont both server and client side(!) That creates the new route. Thanks all for your time and effort