Default port is 1194 and UDP.. While I agree he is using tcp, when you call out forwarding to 1194 - best to make sure you mention that in this scenario it will need to be TCP and not the default UDP port is all I was wanting to point out ;)

You need to isolate whether its a DNS issue or other issue. Can you ping IP addresses from the VPN? ie... ping 8.8.8.8, 1.1.1.1 etc.... if that works its probably a DNS issues, if not then it's some other issue. Can you give more information on the OpenVPN... is it a server or client? When you say connecting to the VPN... what exactly do you mean... from external into your pfSense box? or from the LAN to a VPN provider? RHLinux

@jimp Thanks... that's what I needed to know.... I'll leave things alone.

Yeah that's a really old guide. You couldn't set a gateway group as the default gateway before 2.4 which didn't exist in 2016. You should not have to source NAT traffic out of the LAN. The reply-to tag should take care of sending replies back out of the OpenVPN gateway. The only reason you might have to is if the target server is not configured to allow access from outside it's own subnet. Steve

@gmbarlev There is no difference between routing through a VPN or nor. It's all about your routing configuration. A VPN is simply another interface. So, once you've verified the VPN is working, ensure your routing is correct.

OK, I did some further digging on these lines coming from my openvpn.log file: Mar 11 22:19:57 firewall openvpn[99120]: ++ Certificate has key usage 00b0, expects 00a0 Mar 11 22:19:57 firewall openvpn[99120]: ++ Certificate has key usage 00b0, expects 0088 I found an article on this site which is talking about OpenVPN and remote-cert-tls server option in Advanced Configuration -> Custom options. When I add the option "remote-cert-ku b0" just after the option "remote-cert-tls server" my openvpn client connection status went to "up". [image: 1584029851828-screenshot-from-2020-03-12-17-17-19.png] So now the VPN connection is up I can continue to configure pfsense to route the WAN through the tunnel. Keep you posted if necessary. Thanks for the help so far. Erik

@johnpoz I followed the instructions but after a couple of days the problem is present again, the vpn client has been assigned the IP address: 10.0.2.3 how is it possible ? where am i wrong? thanks.

@tompark said in OpenVPN and NAT from External IP: Does anyone have any suggestions on what I have missed? You didn't mention, what's your problem.

@Rico said in Help With OpenVPN Client Export: I did....but seems I misunderstood. Thought you have one box running 2.4.4 and working with your andoid and another box with 2.3.5 throwing that error. -Rico Ah, I see. I still do have the 2.3.5 box running (not in production, just to fiddle with) but it will be turned into a NAS box shortly. I edited the file and for some reason the export from the 2.4.4 version is not putting my WAN IP in it. Once I added the IP, I was able to import it with no errors. Thanks

@kiokoman thanks for the tip, I have configured a bridge with linux tools (brctl) and I'm using virt-io and I thought that would be enough but it is in fact very reasonable that it would actually introduce limitations and weird behaviors like what I'm seeing, I will dig further the issue

I just wanted to post a follow-up in case someone in the future has the same problem and comes across this thread. We were able to determine that the service account we were using to bind to AD was unable to properly access the entire directory structure (still not sure why not, but that doesn't matter). I could see it make a connection to the domain controller and then attempt to check each of the containers defined in the pfSense authentication server, but it would return "0 users found" in the LDAP query even though the account to be authenticated was there in that container. What fixed it was to add that account we use for directory binding to the Built-In "Account Operators" group. After that everything has worked perfectly.