<smacks head="">  Thank you!  Worked perfectly.</smacks>

Just to update. This does work, but there was a client configuration issue - I had –tls-client but this doesn't imply or --pull (--client does), which is required in order to pull routing information from the server. Adding --pull to the client connection command solved the problem.

OK, I think I found the problem - two of them actually, and theese have to be solved before the OpenVPN would work or further troubeshooting can be done. First issue turned out to be CentOS having a builtin firewall ( ::)) Quite embarrased I dind't catch that earlier actually. I've opened the ports now - atleast an easy solve. :P Next issue is way more major. It seems the entire Duo Auth Proxy service is not working. It was built and installed following a procedure from Duo Security (to the letter) and there were no errors - nevertheless, the service says it's running, but it's actually not listening. - There is nothing on the server listening on port 1812. Running "netstat -plant" shows nothing on port 1812 - and telnet'ing to the server on port 1812 - gets me no connection…. So actually the problem with VPN not authenticating is quite understandable, as the RADIUS is not listening for it's requests! :-\ I've sent an supportticket to Duo Security, and I'm awaiting their response.

For that, both sides would have to be in the same subnet, and you'd need to setup OpenVPN for a tap bridge. It's been discussed many times here on the forum, search a bit and you'll find it.

entering the remote an local networks on both ends should do the trick for simple site-2-site vpn's using openvpn. i've done this a dozen times without fail

You're not alone, but using Shared Key is a REALLY BAD IDEA.  Use Certs and create the tunnel that way.  On the openvpn server, allow the clients to contact each other. Another interesting question I have to ask is why Bridge?  It just causes unnecessary traffic.  If you need to Access Windows shares, either call them by IP or better yet, set up a NetBios Server. Bridging has it's uses, but you're eating bandwidth for absolutely no reason. Pre-shared key is a bad idea as there is no real way to transmit the preshared key successfully unless you pre-encrypt the file and that can be done with AES crypt. Remember Deep Packet Inspection will be able to see the key. (If they are monitoring for that).. If they have the key, they can snoop.  Not exactly secure.  Defeats the purpose of VPNs. Lots of VPN and cloud info. :) Read more on my blog about these issues:  http://swimminginthought.com Cheers.

Everything that goes out your pfsense goes out through the VPN.  Cool stuff.  Many people prefer it.  It avoids deep packet inspection.

I have the same rules in place on both server and client [image: vpnrules.png] [image: vpnrules.png_thumb] [image: lanrules.png] [image: lanrules.png_thumb] [image: wanrules.png] [image: wanrules.png_thumb]

Thanks for your reply heper. I did it already! Please check it below: Proto Source Port Destination Port Gateway Queue   * LAN net * net_vpn *   DSL1 none Where net_vpn is an alias to all VPN clients networks: 10.2.0.0/16, 10.3.0.0/16, …, 10.6.0.0/16 However, while I was writing this reply I realised what was the problem. The rule above changes the default gateway of packages destinated to VPN clients! That way the packages were not routed through VPN interface, but through WAN1 (via DSL1) interface. I just kept default gateway in rule above and everything worked fine. I was blind! Proto Source Port Destination Port Gateway Queue   * LAN net * net_vpn *     *         none Thanks anyway. Eyder

Until you do a sniff your just going to be guessing. Troubleshooting: Unexplained network traffic Step 1) Sniff the traffic to see what it is Step 2) Fix what is causing the unwanted traffic you see in step 1 Step 3) Relax and have a beer.

I have added the route on the OpenVPN server configuration route 10.0.1.0 255.255.255.0; push "route 10.0.1.0 255.255.255.0"; client-to-client; for the OpenVPN client to identify 10.0.1.0 which is Watchguard LAN. The problem would be: route 10.0.1.0 255.255.255.0; That will tell the pfSense end of the OpenVPN that it should use the OpenVPN to get  to 10.0.1.0/24 - but actually the way to 10.0.1.0/24 is your IPsec link. Remove this line, but leave the push line (which tells the client about how to route from the client towards the Watchguard LAN. Hopefully it works.

Did you install the OpenVPN Client Export Utility package? That would be an easy explanation for the client export pages not being found. I'm guessing that, after you restored the config from your previous box, you had to mess about assigning interfaces to the appropriate device names on the NetGate. In that case, the initial boot with the restored config probably could not see the internet and so could not auto-install the various packages referred to in the config.

@networksage: I want the pfsense to act as CA. what do you mean by open vpn server. I am sorry - don't know why but I completly misunderstood your question. So please forget what I said :D

@WildeRex: @Koenig: Started messing around a little with this, but ended up with a nonworking VPN-server, could connect but no access at all to my LAN…. Here is VPN review site. It helped me a lot with my problems : http://topvpnreviews.net/ :D Yeah, thank you, but it seems a bit away from my troubles though….

@Nachtfalke: Probably a firewall or antivirus configuration issue on the destionation host which blocks your ICMPs from other subnets than its own. Yeah, that just hit me like a brick a while ago  :o Have to check on it..