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..

Great - just so you know, does not have to be h-node, you could set that to meet your resolution needs.  H is just hybrid will check wins first if one set, then broadcast. If you don't have any plans for wins, etc then you could just set it to B-node for broadcast only, etc.

Also- In your open VPN rules put your addresses    192.168.0.0/24 ect… Your LAN rules have a lot of redundant rules.    The ANY ANY rule pretty much does it... What version of pfSense are you running?    I havent had a client side openvpn gateway since 2.0.1 came out... Shouldn't have one on the server side... Mine- ifconfig 10.0.8.1 10.0.8.2 lport 1194 Yours (client side)is different from mine…    I don't think yours took...

Through further testing, I discovered that this issue only occurred when doing SMB file copies from a Win7 machine to a Samba server (or vice versa).  The issue was caused by the settings of SO_SNDBUF and SO_RCVBUF socket options in Samba.  The recommended settings of 8192 cause a significant performance hit when transferring files over a VPN.  Changing the settings to 65536 cured the problem completely. Kevin

Bridged puts you logically on the LAN and could be considered easier, but all broadcast traffic will traverse the tunnel and an ethernet header is added to every packet creating overhead. Routed functions essentially the same… you can still connect to network shares, ping LAN IP's, ping by name (/w WINS), etc.  Also, only traffic destined to the client or the LAN will traverse the tunnel making it more efficient.  So... to each their own :) I've never tried a bridged setup, but I'm betting that OPENVPN tab is the OPT1 interface you renamed to OPENVPN and bridged to your LAN per the instructions from http://hardforum.com/showthread.php?t=1663797. If you add a pass any any rule to the OPENVPN tab you should be able to pass traffic.

Yes I do. All/All Pass. Its definitely odd behavior… I have rules on OpenVPN, and All/All pass on each OpenVPN interface, assigned and set. And the block would show as coming from that interface. See, TCP SYN packets get through.. its something to do with state keeping. I am not a pf savvy guy (I know the basics, but analyzing the blocks is a bit beyond me at the moment)

Tried that it though I didn't wait that long enough. I ll just tried again if that works. Thanks

Post your tunnel settings and the firewall rules on your openvpn tab.