First of all, find out the IP address(es) that the hostname in question resolves to. Then on pfSense1 create a static route for those IP addresses that routes through the OpenVPN tunnel. You'll need to ensure that both pfSense hosts know how to route to the LAN on the other side.

It works after changing the MTU only for the wan interface facing the proxy to 1200, 1300 won't work. Weird thing…

Yes, that's it! All the Certificates were corrupt… strange.  ??? But now with the new certificate the Client Export Tool works perfect. Thank you very much...  :)

It should be "good enough" in most cases, though you don't get the extra security of the certificates. The User Auth only still uses a tls key in addition to user auth, so it's still secure. I think there is an open ticket somewhere to open that up so that it can be used for other auth methods. It would just require making the certs in the cert manager (or elsewhere) manually instead of them being tied directly to user accounts as they are with Local auth.

Yeah there have been some UDP issues in the past where the return traffic will use the default gateway regardless of the interface used for connecting when using 'any' interface, though I haven't tried that lately on 2.0 so I'm not sure if that's really an issue these days. Binding to LAN and forwarding ports lets it take advantage of pf's reply-to directive which ensures the traffic goes back out the WAN it came in on.

I've just tested using a 3G modem and works perfectly, I can reach any service available to LAN users form OpenVPN Users. Thanks for your help

Please start a new thread for a new issue, so it's easier for others to find and contribute.

That worked perfectly! I just tested the setup you suggested with 3 test users and had filtering working exactly the way I want. Thanks for the help!

It can be done, but it involves using client bridging and adding custom configs to the server. Stick with the routed solution, it's more efficient and it looks like they are eliminating bridging from 2.0 anyway.

What eventually fixed it for me was swapping the openVPN protocol from UDP to TCP. Up to this day this still makes NO sense to me whatsoever as it all worked though UDP as long as I did't leave the LAN. Accessing remote websites as an openVPN client jsut didnt work using the UDP protocol. I made a small post on my blog explaining the steps I took to get it working. URL : http://henri.kuipersite.nl/2011/02/25/the-alix-project-part-2/ I hope this will give you enough info to get it working for you too. If not (or if it does) let me know via a reply here and/or a little note at the blog :) Happy VPNing

no takers? -Rich

sweet! Good to hear

Is this true even if the openVPN is setup in bridged mode? I can't speak to Bridge mode as I've never tried it, but theoretically then your clients would be on the same IP network so I would say no it probably wouldn't be true for that scenario.  I don't think pfSense has bridge mode as an option out of the box but you might be able to configure that using the custom options field. Yes, it is true that my Internet connection is only 100 Mbit. However, the network between LAN and DMZ is at Gbit speed today. I don't want LAN/DMZ communications to be affected negatively. Well….. pfSense runs on a PC, can you use Gbit NICs?  Or are you running it on an embedded device? -Rich

@jimp: Client should have dev tun, not dev tap. It's always the simple things - that did it!  Thanks! -Rich

huh, it's probably one of the ones with broken hardware checksum offloading under some circumstances, disabling that under System>Advanced would possibly resolve, but you're vastly better off with the Broadcom NIC anyway.  ;D

Okay…all updated to 1.2.3 now. Went through and changed some things back to how they were supposed to be according to the setup guide....and it's working now. Part of this though included having to use a WWAN card to make it so I was attempting to vpn in from the Internet....vs. from my own internal private network.  Apparently, that won't work. :)