By the way, you mentioned that allow dup connections wasn't that great because if one connection was compromised it would mean re-issuing all….  I would only be using the dups for classroom work then probably deleting and making a new ones after class (a day to two) anyway so it doesn't matter...  The ones that will be persistent will be unique. Make sense?

What you mean by " setup route on the box to point to pfsense". I'll describe better the topology: I have some computers with 192.168.0.x subnet and the DG 192.168.0.254. This DG routes to another subnet inside another LAN so i also cannot touch it. Pfsense has internal interface 192.168.0.253 and the external one connects it outside. I setup VPN in order to access 192.168.0.x subnet but because Pfsense is not their DG I cannot access them. Any ideas how I can do it? Thanks.

I'm also running on an Atom D525 with 4GB memory. My Internet connection is only 30mbit down so I am not pushing it by a long shot. Look around on this board or in the hardware section for what other people are running. I am however waiting on a supermicro board with a E3-1220v3 to replace it with. Traffic shaping completely kills the Atom processor. Also the Realtek nics cause high interrupts. Time to get a real server. :) So unless you have a 100mbit connection or want to do traffic shaping you'll be fine with the Atom. You already have the hardware so try it for yourself. Regarding PIA,  I am extremely satisfied with them. I am using them for over 6 months now and I have always been able to saturate my connection. There is some extra lag because of the VPN but not much.  There is someone in my house playing online shooters and he doesn't know he is playing through a VPN.  :p I'm also streaming Netflix over the VPN and it has never failed on me.  On really busy moments like Friday night it might reduce stream quality but I ask myself if that would happen without a VPN too. Please use the latest release of pfsense, there was some bug in versions prior to 2.1.2 where the webgui lost track of the openvpn proces. The tunnel was still working it just showed as down in the webconfigurator.

so is there a way in the current version that comes with pfsense to run scripts when the tunnel is as map network drives automatically when the connection is live and disconnect them when the connection is disconnected pls? I know you can do that with the normal openvpn-gui which works like a charme on xp but I am using wi 7 and do not want to have to click run as everytime  :-( Cheers, Raj

@kpa: I think that I know what is happening with your problem. When the VPN client is active on your server it overrides the default gateway but does not replace it, this is where the 0.0.0.0/1 and 128.0.0.0/1 entries in your routing table come from. When you try to connect to your own VPN service the packets come in via the WAN interface but the replies are not sent back via the same WAN interface because of the two routes installed by the VPN client connection, the two routes are more specific than the actual default route so they will be selected for all traffic sent out from the system instead of the default route. This means the replies to connection requests to your VPN service are routed via this VPN client connection and don't make back to the source. I'm not yet sure how to fix it but at least that's what I think is happening. Edit: You have the firewall rule on WAN interface that allows the incoming OpenVPN connections to WAN interface, UDP port 11194. Change the gateway option on that rule to be the gateway of the WAN network instead of the system default. Thanks, that's pretty much what I thought was going on, I just wasn't sure how to address it. @heper: try to add this to your ovpn-client advanced field: route-nopull assign the ovpn-client as an interface, configure the necessary rules. It should automagically create a gateway for it. This gateway could then be used in your firewall rules on LAN/ovpn-server/… this should disable the default-gateway override. Don't do this remotely … you will probably lock yourself out once or twice ;) I think that is exactly what I was missing.  I added that code to the advanced options, disabled my default LAN route, added a new LAN route specifying the VPN as the gateway and now it seems to work as desired.  I'll have to test it out some more, but initially I believe this has done it.  Thank you very much!!

nb, update. my vpn tunnels have not lost connectivity in over 24 hours. not sure why. thanks, Sean

corp network         |         | pfsense (192.168.60.10) WAN (additional fully external ip resolves to here)         |         | pfsense lan interface (192168.1.1)         |         | Windows radius server (192.168.1.10) OpenVPN Config: Server Mode: Remote Access (SSL/TLS + User Auth) Backend for Authentication: RADIUS Protocol: tcp Device Mode: tun Interface: WAN Local Port: 443 System: Authentication Servers Settings: Hostname or ip: 192.168.60.10 Shared Secret: pasted over from radius server Auth Port: 1812 Accounting Port: 1813 Auth Timeout: 500 Before when I would manually enter a bad password it would show up in the radius server logs.  This time using wireshark, I can't detect that any traffic is even making it to radius.  I can verify with captures that it is reaching the openvpn server.  I think somehow openvpn can't reach the radius server and it is timing out and failing. Like I said I have all rules down trying to figure out why, any help is appreciated.  Pretty sure its something really simple I am just not seeing. Also forgot to add, I didn't change anything about the NPS config from the working connection to the non-working connection.  Still have it set to receive requests from 192.168.60.10. OpenVPN Log: May 21 11:33:38 openvpn: user 'clarkdori' could not authenticate. May 21 11:33:38 openvpn[52966]: 64.134.31.222:63010 WARNING: Failed running command (–auth-user-pass-verify): external program exited with error status: 255 May 21 11:33:38 openvpn[52966]: 64.134.31.222:63010 TLS Auth Error: Auth Username/Password verification failed for peer May 21 11:33:38 openvpn[52966]: 64.134.31.222:63010 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) May 21 11:33:38 openvpn[52966]: 64.134.31.222:63010 TLS Error: TLS handshake failed May 21 11:33:38 openvpn[52966]: 64.134.31.222:63010 Fatal TLS error (check_tls_errors_co), restarting May 21 11:33:38 openvpn[52966]: TCP connection established with [AF_INET]64.134.31.222:63012 IPV4 Tunnel 192.168.2.0/24 IPV4 Local 192.168.1.0/24

Hi all, OpenVPN tunnel is working. After 20 sec. the communication is cut by the PBX because it has no answer to some of its packets. I suspect that pakets sent to 10.0.2.10 (the phone at the other end of the tunnel) are not handled properly (either when sent or received). Is there a firewall rule I'm missing for any kind of packets sent from our local network to the remote phone in the VPN tunnel? As for the packets that looks like they are coming from the external WAN/public IP of the remote phone instead of its tunnel IP address, I simply by-passed by adding rules to accept all WAN traffic. But this is not the solution I expected. Thank you for any help. Best regards, Alexandre Leclerc

look: https://redmine.pfsense.org/issues/282 perhals helps

Ok, this was a silly problem.  I have a multi-wan gateway and a firewall rule that directs anything that is destined for port 80 or 443 and is NOT destined to one of my local subnets to use the mult-wan gateway.  I had forgot to add the VPN remote network to my local subnet alias so it was going out the multi-wan gateway and getting lost.  All is working perfectly now.

Well it looks like it was a routing issue. Lesson here is to ensure that you put all the options provided by your VPN provider from the ovpn file into the advanced section pfSense OpenVPN cleint configuration.  Is was only when I attempted a traceroute from pfsense that I realized there was an issue with routing.  This is of course on top of following all the published guides on this. Once I put the following, based on the ovpn config file, it resolved the routing issues. SAMPLE ONLY (You will need to use whatever setting is provided) persist-key;persist-tun;verb 4;reneg-sec 86400;tun-mtu 1500;route-method exe;route-delay 2 redirect-gateway def1;comp-lzo no;explicit-exit-notify 2;fragment 1390;mssfix 1390;hand-window 30 Thanks, Marco

I am confused, i dont see that option. I am setting a firewall rule on site b on LAN side. But in gateway all i see is WAN

Don't try to manually add routes for OpenVPN clients or servers like that, put them in its conf file.

up Today I used another interface (LAN) and not a VLAN (GAMING_LAN). Now it works fine (I even disabled Server Bridge DCHP options so my local DHCP server handle everything, cool !). But thats not what I want, It must works with my VLAN ;). Could it be an issue because I try to use a VLAN and bridge ?

@JonTheGuy: Where would be a good place to start? Upgrading. That in and of itself might fix it since state killing isn't done by default on gateway failure, or it might be related to other fixes in one of the 6 stable releases since. In 2.0-rel, there isn't an option to disable that state killing short of source editing, IIRC 2.0.1 was the first with that as a GUI option.

Problem Solved. The problem was expired password of the user that I used to verify users authentication.

Am I missing something or does that have nothing to do with pfSense? It looks like it's for connecting Tunnelblick to someone's VPN provider (and not pfSense) Curious why it was posted here, rather than a forum dedicated to OpenVPN directly (or that specific VPN provider)