Correct, and if you check the box for strict user/CN matching then they can't get in unless the CN of their certificate matches their auth username.

@emil92: (…) PS: I am curious if you know if I will have problem routing all the other Sats to eachother so they can communicate directly with eachother? Maybe that function is not possible in OpenVPN. Maybe I have to open a server on each client and connect another client to that one so I create a complete circle. And last Thank you for you help. This can be done with OpenVPN. Every Client must have the iroute command for the subnet(s) behind it. The rest can be done by the openVPN server: For example: You have Server A Subnet Client B Subnet Client C Subnet First: Client C needs the iroute command for Subent C Client B needs the iroute command for Subent B Second: Client B needs to know the route to subent C Client C needs to know the route to subent B You can do this by add this rout on every client - but this is complex when you have many sites. So you can do this from server site: On OpenVPN server: Add a route to client C subnet Add a route to client B subnet Client specific override: For client C add the route to subnet B For client B add the route to subnet C So Clients on subnet B can communicate through OpenVPN with clients on subnet C. But of coure - the traffic is going from subnet B to server A and from server A to subnet C. There is no "direct" connection between B and C. So when you cinfigure this just think about: Should the network behind be reachable by OpenVPN then use "iroute" command Which networks do I want to reach use "route" command If you do this from every VPN endpoint then it will probably work. Firewall rules: First and best thing is to: Allow  "any to any" on the OpenVPN firewall tab Allow traffic from your LAN to ALL OpenVPN subnets (tunnel network) and the networks behind the other VPN clients (the network for which you used the "iroute" command). So better allow too much the first time to check and make sure that it is working. Disable the windows firewall on destination host to make sure that pinging is allowed. If all routing is ok, try to shrink the firewall rules.

With UDP on multi-WAN, the return traffic will follow the default route when bound to "any", it has nothing to do with CARP. The usual fix is to bind the OpenVPN instance to the LAN address and add port forwards from each WAN into the LAN IP on the OpenVPN port. Works just fine that way.

The OpenOSPFd package is a bit broken these days, you might give my Quagga-OSPF package a spin (after removing OpenOSPFD), settings are essentially the same between them, but Quagga appears to work much better with FreeBSD's routing tables, whereas OpenOSPFD still seems to assume it's working on OpenBSD even when running on FreeBSD…

SOLVED!! Awesome. I really excited about this. In order to resolve this issue, I first, completely uninstalled OpenVPN from my laptop. (again) I then created a new user on the firewall. I made a cert for this user as well. Then, and this is the big difference… I exported the windows installer instead of the files themselves. I emailed that to myself and downloaded it to my laptop. I installed it, and noticed that it installed TAP 0901... I tried to log in and it worked. I then tried to access my other computers, and it worked flawlessly. I hope this helps someone else out in the future!

hi. i was experiencing this same issue. i was looking up resolutions and came across this post. http://forum.pfsense.org/index.php/topic,45600.0.html i then switched around my dns servers which were: DNS1 4.2.2.2 DNS2 8.8.8.8 to DNS1 8.8.8.8 DNS2 4.2.2.2 and I checked the box labeled "Allow DNS server list to be overridden by DHCP/PPP on WAN" on the same configuration page. and it allowed me to download.

@marvosa: I'm not sure if this is only generated for routed setups, but Under VPN -> OpenVPN, in the Tunnel Settings section, there is an option for Inter-client communication with a check boxed labeled "Allow communication between clients connected to this server".  If it's there, check it. Otherwise, it looks the switch for inter-client communication generates a server option labeled: client-to-client you can try adding that to your advanced config box. Also, make sure it's not just the software firewall blocking ICMP. That was exactly the problem. I was just logging in to post that the problem is solved! The only weird quirk now is that Clients can't see games that I host, but I can see theirs.  Time for more testing! :D

Sorry I explained badly. The problem was the default gateway of server (192.168.20.2) that is on the same network interface LAN (192.168.20.1) Server pfSense. The default gateway are another address now is 192.168.20.1. Now the client that connect to pfsense throught openvpn che see the server (192.168.20.2). Now the problem is inverse, from the server 192.168.20.2 that has default gateway the private address of pfsense server (192.168.20.1) can't ping address outside the pfsense server. How do I retrieve the configuration to be put on the forum ? thank's Cesare

@Nachtfalke: Users and certificates are stored in the config.xml file. So if the hardware was the only issue to change you only had to copy the config. Ah, that's great to know. Thanks!

thanks all for replaies, I used this link to install and config Openvpn client in my Centos servers http://www.techrepublic.com/blog/opensource/how-to-set-up-a-linux-openvpn-client/1894 After that i get my client config files from " export client " and the CA file and put it on my Centos server Also, i disable the firewall on my Centos then i run Client.conf. this message appeared openvpn client.conf Wed Mar  7 04:23:45 2012 OpenVPN 2.1.4 i386-redhat-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] built on Apr 24 2011 Wed Mar  7 04:23:45 2012 NOTE: OpenVPN 2.1 requires '–script-security 2' or higher to call user-defined scripts or executables Wed Mar  7 04:23:45 2012 Cannot load private key file jrcfw01-udp-2198-tls.key: error:0906D06C:PEM routines:PEM_read_bio:no start line: error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM lib Wed Mar  7 04:23:45 2012 Error: private key password verification failed Wed Mar  7 04:23:45 2012 Exiting any new suggestion. thanks.

@jimp: I don't think there is a howto, but I'm fairly certain I've gone over the whole config elsewhere on the forum in other posts. http://hardforum.com/showthread.php?t=1663797 There is the guide.  I can copy pasta what it says once I test and make sure it works.

So that time must really mean that they aren't connected at all (connected time is null/zero…) if I can reproduce that sometime I'll try to code around it.

For a site-to-site setup, you don't want to use the wizard. Use a shared key setup, check the doc wiki there are several examples.

Removing "auth-nocache" from client configuration files indeed resolved the issue. Although encouraged by OpenVPN to use this option in the client configuration apparently when the data channel renegotiates the keys cached credentials are needed or re-authorization is required to keep the connection active! Thank You for the fix Wasca!

@Wasca: I'm using TUN, should I be using TAP? tun is fine.  Typically though, when I do tunnels, I have the tunnel network on a different subnet that the network that the clients will be trying to reach. ex.  For my home, I have 10.10.6.0 /24.  For my buds to VPN to me and grab stuff from my server, they are on 172.17.0.0 /28. The issue might be that the tunnel network is using the same subnet as the network you're trying to access.

Well, it not working on the one of the WANs, only to the second: I have deleted the floating rule for the WAN in question, created a NAT rule and the corresponding FW rule. I have let the other floating rule untouched, though: NAT Rule [image: natmap1196tolanif.png] Firewall rule [image: allowovpntocyta.png] I have added the info to the Client export for Viscosity: [image: clientq.png] However, Viscosity conf contains the info for the 1st WAN address, nothing for the second: dev tun persist-tun persist-key proto udp cipher AES-128-CBC tls-client client resolv-retry infinite remote 1st_WAN_address 1196 tls-remote VPNServer auth-user-pass comp-lzo ca ca.crt tls-auth ta.key 1 cert cert.crt key key.key The connection is failing, the log is below, and if by hand change the WAN address in the conf file to the 2nd WAN address the connection succeeds: Mar 03 14:38:46: LZO compression initialized Mar 03 14:38:46: UDPv4 link local (bound): [undef]:1194 Mar 03 14:38:46: UDPv4 link remote: 46.198.128.106:1196 Mar 03 14:39:46: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Mar 03 14:39:46: TLS Error: TLS handshake failed Mar 03 14:39:46: SIGUSR1[soft,tls-error] received, process restarting Best regards Kostas

This is route 10.123.45.0 255.255.255.0; The subnet of the roadwarrior from site A that added to site B

I figured it out. I'm using TLS + username password, and I had auth-nocache set in the client config. After I removed that it was all good.