Also adjust your Windows box's firewall to allow pings from outside their subnets.

I thought it would let me go to the other page to change the DHCP range. Those two options should be on the same page! We were all new once, right?  ::) Fixed it. So now my network is 192.168.100.0/24. And everything works. I think.  :P Thanks everyone for the help so far.

Thanks, this work, thanks for you help

So what about the vps idea?

@itguy001010: If I dont redirect traffic then I can control it with which local networks to access but I want to used traffic redirect so as to get the same public IP address as the VPN server it is as soon as I give this ability that the VPN Client can access all networks. With "local networks" setting in OpenVPN setup you can just specify the routes which should be pushed to the clients. But this wouldn't deny access to your networks. You can add additional routes to the client so you can access other subnet if it is not inhibited by firewall rules on pfSense. So access permissions are controlled by firewall rules. I assume you will have an any to any allow rule at your OpenVPN interface. To prevent DMZ access edit this rule, check "not" at Destination area, change type to "DMZ net" and save it. This rule will permit access to anywhere, but not DMZ subnet.

@thermo: Well you don't really need to run as admin  if you install the service part. You mean the management interface? Well, I have yet to find a box where it works (as opposed to just confusing itself with config file locations and making itself completely no-op).

A "smart card" never lets the private key out.  It performs the crypto operations onboard. The host has no access to the key. With your typical OpenVPN installation, your private key is just a file.  Perhaps password protected, but in-the-clear for the host to snag when connecting. The problem with the tokens/smart cards is operating system support.  You can get it working but it usually requires drivers, client support, etc.  It's really a downer the industry couldn't cooperate and come up with something universal and open.

https://community.openvpn.net/openvpn/ticket/301 so if openvpn 2.4 ever gets released …. maybe

And is that computers firewall setup to allow you too? A machine being static or dhcp has nothing to do with it - unless you messed up the mask/gateway or something when you set it as static.  Or it is out of the range you setup for local networks in your openvpn connection.  Did you setup using your /27 vs the actual whole /24 ?

While you're making the change, get a domain, free DNS hosting on HE.net, and change your clients to connect to a hostname instead of an IP address. Then to change your clients in the future you make one change to DNS and you're done.

i also have a J1900 CPU and get full 100MBit VPN speed on my 100MBit line (pfsense 2.2.2). so yes, it seems that possibly your version has some kind of bug that slows down the connection.

It is unclear to me if all those ports correspond to outbound destination ports or just the inbound ports that need to be forwarded. You might have better luck identifying the traffic you want to go out the VPN, checking Don't pull routes in the VPN client config (thereby not accepting a default route from the VPN provider), and routing specific traffic to the VPN instead of trying to exclude games from the VPN. Either way, you need to pick a default route (either your WAN or the VPN), identify the exceptions, and policy route that traffic accordingly.  The traffic easiest to identify should be the exceptional traffic, with everything else going to the default gateway. Also, look at these: https://doc.pfsense.org/index.php/Firewall_Rule_Processing_Order https://doc.pfsense.org/index.php/Firewall_Rule_Troubleshooting That last rule on LAN will never be processed because the rules above it will match first. How to identify traffic for Blizzard might be better asked in the Games forum.

@tkb: In my certificate lineup, they are all User Cert   OpenVPN Server and I have no distict Server certs. So, they're combined. They're not combined. OpenVPN Server is not a cert attribute, it's just where it's in use. What johnpoz is referring to, and what matters, is the left column he highlighted in one of the screenshots.

when you configure the client, do you fill in the tunnel network or is it enough to define this on the server ? I always do to make sure it's correct at both ends, I use a /24 subnet even though it's often overkill.  It needs to be the same in the Client Specific Configuration entry for each client as well. on the server > advanced;  do I understand it correct I have to add the route for every extra branch office ? Yes that's correct, you list the all subnets that the server will route to any of the clients and then add a specific "iroute" in the CSC entry for each client according to the subnet that client needs. In pfSense 2.2.4, it's easier to use the "IPv4 Local Network/s" and "IPv4 Remote Network/s" boxes (although the "old" Advanced box method still works). The "Local" box is a comma delimited list of all of the Server's subnets, while the "Remote" box is a comma delimited list of all of the Client's subnets. As noted above, CSC entries split them where they need to go. The only other thing I've run into when adding new pieces to an existing OpenVPN setup is that pfSense does a fairly good job of trying to keep it's pfSense servers and clients up and running.  That sometimes means when you make changes on the fly, you have to explicitly stop the server and client one at a time and then restart both to make sure your changes are in place.  Changing/adding certificates on the fly can be very problematic sometimes. Seeing as you have two sites working OK, you probably have the basic techniques done correctly.  I would make all the entries in the server for all the clients, then reboot the pfSense server box.  Then you can work on each client one by one and see the changes in the server's OpenVPN status log to see what's going on. In the end I find this stuff takes more time to describe than to actually get going, especially if you've managed to get two clients working already. Keep at it and let us know how it goes.

If you have a failover , and ovpn is runing on that then server run on the tier 1. Tier 1 drops , ovpn runs on tier2.  When tier 1 came up , ovpn changes