The log shows the problem, and even links you to a FAQ entry telling you what to check - see here. If you're using Windows Vista or Windows 7 ensure you run the client as an Administrator (right click -> run as administrator).

Please take a couple of seconds and do a little research for yourself.  There is already a detailed howto on this subject:

http://doc.pfsense.org/index.php/Tutorials

Ok, that was the solution.

I added the routes in static routes in both Pfsense and the OpenVPN tunnel now goes through the SDSL lines. (I think only a static route in the distant site is required).

Thanks !!

The client has to know to send that traffic over the VPN in the first place, which requires routes, which requires administrator privileges… No way around that on the client side.

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.