Hi, Has anybody any other recommendations for a vpn provider? Thanks Richard

I had the exacy same problem for quite some time, and it's still not quite clear to me why it doesn't work, but this is what I found: The port forwarding itself work just fine, the problem is when you combine this with policy routing in such a way that you need a policy route to "activate" to route the traffic out through the correct interface. Since the incoming, port-forwarded packets are placed in the state table, and thus when the computer on the inside replies to that packet, the reply is automatically accepted via the state table. Because of this, the policy routing rule is never evaluated, and thus the packet defaults to the default routing table - usually ending up exiting through your WAN, not the VPN tunnel. Since these addresses are normally in a private range, the packet will just die alone in the cold in some router out there on the internet. In pfSense 2.1 they have made some fix to this that auto creates a "reply-to" rule when you create an incoming NAT/port forwarding. This works, and you can find it in rules.debug, but for some reason it doesn't seem to be executed correctly in all cases (not in my case atleast). What I did to correct the issue, was to make a floating rule, placed on top or near the top of the floating rules, that basicly exactly matches the auto-created interface firewall rule that the NAT/Port Forwarding rule generates. The only visible difference for me, is that this rule ends up much higher up in the rules.debug ruleset, but it makes all the difference - and suddently the portforwarding from a openVPN tunnel works perfectly.

One change I did:  When the upgrade came to 2.1 I checked the previously unchecked box asking that the master and backup synced via pfsync for OpenVPN.  So either something about the upgrade broke site-site or checking that box broke site-site. As a test, I unchecked the box and disabled the client and the server setup on the backup pf box, leaving them run on the master pf box on both the client and server ends of the site-site.  And… after a reboot... it works now. Site-Site OpenVPN does not like the openvpn HA pfsync box checked.  I suggest to check it during the configuration of the master, then before enabling the setup, save it disabled, so the backup PF box gets the config.  Then uncheck pfsyncing the OpenVPN, then enable the config on the master.  The good news is that it will work.  The bad news is that should the master go down you'll have to manually get up at 3 am to enable the config on the slave.  I think it is a rule that PFsense boxes only fail at 2:45 am.

No, I also cannot connect locally, though the openvpn services shows as running. Also tried to reboot PFSense, but no change.

@jimp: If you connect and then are disconnected a minute later, the most likely cause is having two clients connected with the same username/cert at the same time. When one connects, it will work for a minute, and then the other one will reconnect after 60 seconds and bump the first one off, and then it will work for 60 seconds until the first one reconnects and bumps it off, repeat, repeat, repeat… Hi, thx for the reposnse. I have try with windows, mac, linux, iphone, android, etc…. and the connection is very instable... In the GUI I view only one connection and I'm sure that the client try to conenct once. About 10 - 15 days ago the OpenVPN works perfectly...

Not enough information to tell there. You'd need to see the logs from the server side to say for sure. The traffic may not make it all the way to the server, or there could be a mismatch elsewhere in the settings that prevents it from linking up.

The credentials for the VPN are not related to the credentials for mapping drives, they have no shared knowledge. Windows has a long history of refusing to save share passwords as expected. Some versions you have to go into the user account settings and manually add an entry for the server and password. Others you can get away with accessing \x.x.x.x directly and then checking "save password", either way, that's all up to the client OS, not the VPN.

Sounds like the RADIUS server to me. Perhaps there is something in NPS on server 2008 that is causing the logins to be rejected. It sounds like it should be logging more than what you're seeing. http://technet.microsoft.com/en-us/library/cc753898%28v=ws.10%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/bb892007%28v=vs.85%29.aspx

the idea is to browse the vpn I was watching the other examples like StrongVPN and TUVPN that there is nothing vpnbook? or I can help you pull and q aprobechar vpnbook is free

Sonicwall is using 10.0.0.0/8 for its LAN network. That conflicts with the tunnel network that you have chosen. So the server pfSense will be confused about where 10.0.8.0/30 actually is. Either: I can't believe that your main office needs 10.0.0.0/8 for a LAN. If it just uses address like 10.1.1.* then make it 10.1.1.0/24 or even 10.1.0.0/16 - but that might be rather difficult for you to implement. Choose a tunnel network in different private IP space - for some reason you have already used the whole of 192.168.0.0/16 as the client end LAN? 172.16 is still possible, makeup a tunnel subnet like 172.16.42.0/30 At main office, Sonicwall will need a route to 192.168.0.0/16 through pfSense LAN IP 10.1.1.253 - this will allow systems on main office LAN to send packets to your client end using their default gateway (Sonicwall) which will redirect them to pfSense.

Make sure the "interface" of the OpenVPN client is selected as a CARP VIP on WAN and not "WAN".

From your description, it sounds like pfSense site A and pfSense site B have OpenVPN servers. But then you have the message: The logs on the pfsense at site A only mention " Inactivity timeout (--ping-restart), restarting " That is generated by a client when it tries to connect every minute. Give us a network map and details of what OpenVPN servers and clients are where.

it's a strange setup you have there. normally ALL devices in the network should have pfsense as their gateway. is there a good reason not todo this? i currently don't know why you have your AD as gateway? is your AD doing NAT ? Anyways, there are solution to your current problem. But fixing the gateway on the clients is the best option, hands down. If for whatever reason, you can't/won't change the gateway to pfsense on your LAN devices, let me know and i'll try to explain how you can try to circumvent your network issues. (clue: NAT your lan-subnet over the VPN)

@jimp: Sure that works fine. OpenVPN doesn't check the source IP of the traffic, only that the keys and/or certificates match. You can restrict access to the VPN process with firewall rules if you wish. Most limitations of dynamic IPs can be sidestepped with Dynamic DNS if you want to still be somewhat strict. any place to find some documentation to do this? I cant get the clients behinde the home pfsense to get ip from the DHCP server on office.

Okay, logging is turned on and everything is passed. logs: pass Oct 6 14:47:32 LAN 10.0.11.107 10.0.0.2 ICMP the routes look way better now on the pfsense: IPv4 Destination Gateway Flags Refs Use Mtu Netif Expire default 85.126.29.201 UGS 0 38 1500 em1 10.0.0.0/24 10.0.1.5 UGS 0 36 1500 ovpnc1 10.0.1.0/24 10.0.1.5 UGS 0 0 1500 ovpnc1 10.0.1.5 link#10 UH 0 0 1500 ovpnc1 10.0.1.6 link#10 UHS 0 0 16384 lo0 10.0.10.0/24 link#3 U 0 0 1500 em2 10.0.10.11 link#3 UHS 0 0 16384 lo0 10.0.11.0/24 link#1 U 0 3994 1500 em0 10.0.11.11 link#1 UHS 0 0 16384 lo0 85.126.29.200/29 link#2 U 0 174 1500 em1 85.126.29.203 link#2 UHS 0 0 16384 lo0 127.0.0.1 link#7 UH 0 33 16384 lo0 but I still have no connection to 10.0.0.0/24; though pinging 10.0.1.6 works

Ah…yeah, so I see that one firewall I'm using RADIUS for OpenVPN on doesn't work with client-connect defined. This seems like a bug - is there a workaround? Is it a known issue? Edit - I could just call my script from the attributes script...though I'm looking for something clean. Meaning, I get all the environment variables, etc.