If you touch an assigned tun interface on 1.2.3, you must edit and save the associated OpenVPN client or server before it will function again (which will restart it). That works fine.

That should work fine, I've done that a time or two in the past.

Bridging is ugly and really isn't needed. Firewall > NAT, Outbound NAT tab Switch to manual outbound NAT, press save. Add a rule, interface is LAN, source address would be your VPN subnet. Destination would be your LAN subnet, translation address would be 'Interface Address'. That should be enough

yes i pushed the wins server throw the tunnel to vpn-clients. i test it tonight thanks for tipps havok

Thank you very very much! Could not see the wood for the trees….

Success!  Thanks CMB!  That makes sense; I guess I just happened to luck out that the client had the same default cipher as pfSense.  Now to work the magic with a DD-WRT router; I've heard they are a bear to get working.

After having thought a bit more about the wordings in pfSense book at 15.6.2 I believe I may have made the incorrect assumption. It looks like one may at any time enable or disable them using that setting at System | Advanced. If this is the case, can someone help my understand why the FW rules for the interface isn't working? TIA,

@jimp: The files in /var/etc should not be touched. They are created by the system from the data in the config, and those are what openvpn uses while it's running. As for the config entries that can't be deleted, there is a bug in 1.2.x that sometimes causes a stray "<config>" tag in certain areas. If the blank entries are a problem, just make a backup of the config, find the "<config>" tag under the openvpn server and client settings, and restore the edited config.</config></config> Ok, thanks, will make a note of this.

Bumps require payment to pfsense team if done less than 24 hrs  ;) So the one that is not working, does it even connect? If not look at the config files make sure they match on both sides.

Thanks it worked!

jaja - das ist ja geradewegs perfekt! manchmal sieht man den wald vor lauter…. DANKEEE

@jimp: No, if it's PKI then you can push and you fill out local and remote networks normally. You really should just need the proper routes then. Most people don't do PKI for site-to-site which is why I mentioned the other limitation. Thanks, the information you provided helped tremendously.  Now that I understand the routing and limitations of shared key, it all makes perfect sense.  Everything works as expected now.

No, it means that when you run a VPN (encrypted tunnel) you need higher specification hardware to handle the bandwidth - regardless of your choice of platform. A box that can handle 50 Mb/s of unencrypted traffic may have problems with 10 Mb/s of encrypted traffic. A lot will depend on what VPN technology you use, what level of encryption you decide upon etc.

hi, so there is no way the server can deny a second connection with same certificate? cya

Vayatta may config their openvpn servers differently (perhaps using tap rather than tun). You can use any non-overlapping RFC1918 (or even public if you really want) block for the address pool, but the way OpenVPN assigns addresses (it carves /30's out of that /24) is well documented by OpenVPN: http://openvpn.net/index.php/open-source/faq/77-server/273-qifconfig-poolq-option-use-a-30-subnet-4-private-ip-addresses-per-client-when-used-in-tun-mode.html