Thank you jimp and kpa for taking time to reply to my post. I think this script has to wait for the vpn to be up and running before it launches. Anyway I have found the solution to launching the script correct over at https://forum.pfsense.org/index.php?topic=71725.msg756541#msg756541

Glad it's working. There is another reason you have to have the rules not match the OpenVPN tab and only match the assigned interface tab. When they come in passed by the assigned interface rule, the resulting states get flagged with reply-to so the reply traffic gets sent out the interface on which it arrived - back out the OpenVPN tunnel in this case. If the traffic is passed by the OpenVPN interface group tab, there is no way for the system to know which interface it arrived on (it could be any interface in the group) so you don't get reply-to. The reply traffic will be sent according to the routing table which probably means it will be sent out WAN (and die there being out-of-state).

My RADIUS and AD is running from windows server 2008. There's no Google Authenticator package that can integrate with windows machine as far as i know. Thanks, I'll look into the freerad package for pfsense. If I do this, will I be able to configure freerad through commandline and use apt-get to install additional packages for the freerad?

Those are not placed by an OpenVPN server but by an OpenVPN client connecting to a server. Did you assign an interface? Add outbound NAT?

It was that damned CloudFlare rule. I re-ran the list of places that previously showed the VPN IP and they all reported the real WAN IP as expected. I really hope this consistently fixes it.  I'll update the thread if it doesn't fix it after I've pulled some hair out. (BTW, those Facebook IPs are straight from Facebook so only include their CIDR blocks and nobody else.  Back when that info was public.) Shows VPN IP TorGuard.net –> Shows real IP :) DuckDuckGo "What is my IP" --> Shows real IP :) whatismyipaddress.com --> Shows real IP :) BearsMyIP.com --> Shows real IP :) ipchicken.com --> Shows real IP :) ipaddress.pro --> Shows real IP :) Anecdotally, this also tells me just how many sites are CloudFlare customers (at least the free account).  Holy crap it's a lot.

What warning? The client is told what CA to use in the export file. It's not like an SSL connection to a web site. It is a VPN. If you could use a public CA for your OpenVPN server, then ANY certificate issued by that public CA would pass. And you wouldn't be in control of revocations, etc. Export the configuration for the client. That's how it works.

That is because you already have that route in the routing table from your other connection. #notabug Diagnostics > Routes

I was able to resolve the problem! There was some weirdness going on because I had set up the machine on an internal network. johnpoz was right, in that the problem was in the routing table of the internal machine. Once I fixed the internal machine to use the firewall as a gateway, I was able to VPN to it from the external machine.

You don't have to use the OpenVPN installer that comes from the export package if you don't trust it. You can instead download the installer directly from the OpenVPN site: https://openvpn.net/index.php/download/community-downloads.html

@viragomann: Ping uses the ICMP protocol, so you have to add an additional rule where you allow that. Thank you was a NAT issue which we got resolved now. thank you for your answer

I am experiencing the same problem. I have my pfSense box connected to StrongVPN and I see this in the logs: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1558', remote='link-mtu 1562' WARNING: 'mtu-dynamic' is present in remote config but missing in local config, remote='mtu-dynamic' When I put tun-mtu 1500 in the Custom Options, like you the warning changes.

So these new devices are pointing to pfsense as their gateway? Do they have host firewalls on them that could be blocking your tunnel network.. Why you should think its pfsense preventing access to devices on a network it allows access to seems a grasping at straws sort of thing without even basic troubleshooting.  Do you filter your vpn traffic to allow only access to specific IPs?  If not pfsense has nothing to do with the problem. Does pfsense have the mac address of these new devices in its arp table.  Can pfsense ping these devices from its interface in the 10.1.0.0/24 network?

@kip: I just need a new OS on the system. ??? Whatever you mean by that.

Are you pulling default routes from your vpn server your running.. Then yeah it would route all traffic through your vpn.. If you want your dmz machines to use the tunnel and your other machines to use your that is basic policy routing.. Just send the dmz or any IP you want out your gateway you created for the vpn connection.  Let your other clients just the normal routing of pfsense which should send it out your wan, etc.

A quick update on this. I disabled my new config and created a new one from scratch. This time it works the way i want to. I have no idee what happend with the old one…