Hi, just to make sure what you have: You have one WAN connection and one (or more) LAN connections? Some traffic from LAN to the internet should go through the VPN and other should go through your origin WAN, right? It could be usefull to see your firewall LAN rules and if you have really PortForwarding enabled then the firewall rules on your WAN interface - at least for the PortForwarding rule.

I deactivate the windows firewall and the AVAST firewall. Best regards Thierry

@NOYB: Does not prevent account from WebConfigurator login.  Just restricts access to WebConfigurator pages. Check cmb's post…  that was exactly my point.... don't put them in group that has access. Only works for OpenVPN connection access. You can put those rules on any interface. Not difficult to find the changed and non disclosed WebConfigurator port. So, change it and install firewall rules to harden access.  Not difficult to keep people out with firewall rules.

I was able to figure out a script to replicate the behavior that occurs when the save button is clicked on the client.  This is a little bash script for those who need to restart a client cleanly (i lose 1 ping during the restart).  Save this as a .sh file, chmod +x that file and add it to cron or trigger it however you would like.  I'd like to somehow trigger this by an Apinger Down event, but I don't know how to do that.  Can anyone help with that? #Determine the PID of the running client (assumes there is only one) clientpid=$(pgrep -lf /openvpn/client | awk '{print $1}') #Collect path of openvpn and client openvpnpath=$(pgrep -lf /openvpn/client | awk '{print $2}') clientpath=$(pgrep -lf /openvpn/client | awk '{print $4}') #Kill client process kill $clientpid sleep 2 #Restart the Client $openvpnpath --config $clientpath

If both sites run PFsense, why are you doing Road Warrior and not Site to Site?

That looks like a certificate verification error, so something in the CA/Cert doesn't match or isn't right between the client and server, or it's invalid in some other way.

Never mind. Found it.

Anyone at all? Any opinions?

Thanks for coming back to me. It's now fixed. The issue was laptop privileges, in the end. Once I ran OpenVPN as the administrator, then it worked fine.

Aha… Figured it out from: http://doc.pfsense.org/Create-OpenVPN-client-to-TUVPNcom.pdf I needed to create an extra interface and gateway. All seems to work OK now...

A good place to start is to understand how tunnel networks work. http://openvpn.net/index.php/open-source/faq/75-general/293-what-is-the-principle-behind-openvpn-tunnels.html

The rules on an interface tab apply to traffic coming IN on that interface. The first packet when a "connection/flow/session" is first started is checked by the rules, then if it is permitted, a firewall flow/state is added, and subsequent packets in both directions that match the flow/state are allowed. Thus, to get out from LAN (to the internet…) a suitable pass rule is needed on LAN. For a connect coming from a client on the other end of an OpenVPN link, a rule is needed on OpenVPN to allow the incoming connect. Once the flow is established, the traffic in both directions for that flow "flows":) That might be enough to give you the concept and you will be able to apply it in practice.

Thank you Phil for all your help.  I finally got it up and running with your help and Jim's help.  Once I got the OPTn set to openvpn I had to set outbound nat on SITE A for SITE B to get out to public. All seems to be working good so far.    Now I will work on getting NAT working for the servers in SITE B through SITE A.

@jimp: @CuriousG: Edit2: Site C will not always be up, will this affect communication between site A and B? Avoid using "edit" to ask questions. It does not notify that the post was updated the same way a reply does. If C is just another client, it won't affect anything between And B. If A were down, then B could not reach C, but that is the only failure that would be a problem. Thanks.  It makes perfect sense if A was down since it is the "server".  Only reason I asked is I got a call today that they weren't able to reach A from B but since this user is a handful in the first place I didn't know what to think when I activated site C and everything was fine.

Hey, I have been trying to use your patch and can't work out what I'm doing wrong. I applied the patch OK and created a new entry in 'System: Authentication Servers' then configured OpenVPN server to uses it. Any help would be great The System: Authentication Servers entry: System: Authentication Servers Descriptive name OpenVPNUsers Type LDAP LDAP Server Settings –----------------------------------------------------- Hostname or IP address 10.10.10.10 Port value 389 Transport TCP Peer Certificate Authority internal-ca Protocol version 3 Search scope Level:  Entire Subtree Base DN:  DC=domain,DC=com,DC=au Authentication containers Containers:  CN=OpenVPN Users,OU=Users,DC=domain,DC=com,DC=au Bind credentials User DN:  readonlyuser Password:  password User naming attribute samAccountName Group naming attribute cn Group member attribute memberOf OpenVPN Log: Jun 6 15:51:24 openvpn[45763]: 49.176.33.77:19534 [] Peer Connection Initiated with [AF_INET]49.176.33.77:19534 Jun 6 15:53:55 openvpn[45763]: 49.176.33.77:19534 Re-using SSL/TLS context Jun 6 15:53:55 openvpn[45763]: 49.176.33.77:19534 LZO compression initialized Jun 6 15:53:58 openvpn: : Now Searching for janedoe in directory. Jun 6 15:53:58 openvpn: : The container string contains at least one group, we need to find user DN now Jun 6 15:53:58 openvpn: : User found Jun 6 15:53:58 openvpn: : Now Searching in server OpenVPNUsers, container CN=TechNet OpenVPN Users,OU=Users with filter (samaccountname=janedoe). Jun 6 15:53:58 openvpn: : Search resulted in error: Success Jun 6 15:53:58 openvpn: : ERROR! Either LDAP search failed, or multiple users were found. Jun 6 15:53:58 openvpn: user janedoe could not authenticate. Jun 6 15:53:58 openvpn[45763]: 49.176.33.77:19534 WARNING: Failed running command (–auth-user-pass-verify): external program exited with error status: 255 Jun 6 15:53:58 openvpn[45763]: 49.176.33.77:19534 TLS Auth Error: Auth Username/Password verification failed for peer

Well, I figured out half of my issue… In the OpenVPN configuration, I mistakenly assumed that leaving the "Concurrent connections" field blank would default to unlimited, but once I plugged an arbitrary positive integer in there, VOILA!  My Tunnelblick client on the Mac can now fully establish a connection. I still can't get the Windows machine to connect.  I originally installed the client, the imported the configuration from the client export package.  I think I'm going to try and use the Windows Installer export instead and see if that fixes the issue.

Yes, so long as a route is pushed for the other tunnel network. e.g. the UDP VPN pushes a route to the client's for the TCP VPN tunnel network, and vice versa.