So do I, less problems and more secure, but can be harder to setup.

Got it. Makes sense. Thanks again jimp!

Try again with a new snapshot. If it still fails, odds are you had the Site-To-Site (SSL/TLS) connection configured improperly, it isn't addressed like a shared key setup, and there was a bug in the code earlier that wasn't correctly setting up the configuration.

Do the devices in the 164 range have a default gateway other than the pfSense? Do you have the OpenVPN instance assigned as interface? If yes, might you have a rule not allowing access? The same on the remote side: Might you have a rule not allowing access? Do you see anything in the firewall log?

Hi jimp, thanks for feedback. Just wanted to be sure that I didn't miss anything in the pfsense config.

It might not be too hard to implement, but as with everything, it does take some time. It would just require adding another checkbox to unhide a custom options box, something like the password box does now, and then some extra code to get the options into the client config.

Doesn't look like the traffic is even hitting the second pf box….but surely it wouldn't be hitting the firewall of pfB since it's LAN > LAN traffic? EDIT: now solved so forget the above - (had to change the source on the default LANnet rule from LAN Subnet to 'any')  :-[

FYI- this should be working in current snapshots (and with a current/updated openvpn-client-export package)

server: pfsense 1.2.3 client openvpn gui 1.0.3 I used the 2.0 folder to create the keys, certs, etc

I'm willing to give it a go if you can point me in the right direction  :)

Had to wait a while to be able to upgrade the remote side, but I am happy to say that it is working just fine after updating to the latest snapshot on both sides. Thanks for your help jimp!

It won't simplify it, the routing on PSK is much simpler than SSL/TLS. The rest is a matter of preference.

Ok Jimp , i have modified the network like this 10.0.8.24/29 instead of 10.0.8.25/24 and now it is working. Probably the issue was the first time when i have defined the VPN … and now because some thinks are verified it's not working like in the past . Anyway i have understand where was the problem f I was careful from the beginning in defining correctly the whole discussion would not have made ​​sense. Great work guys , Thanks. Best Regards, Daniel

You could upgrade to pfsense 2.0. I believe its running OpenVPN 2.2 I can't speak for the devs, but I dont think they update packages for new features. Only for security updates.

Problem solved in a way. When I moved to SSL/TLS VPN with a certificate on both ends the tunnel worked perfectly, without making any other changes.

Problem was faulty router (ZyXEL 660H-T). For this and other oddities… Damned! It mede me crazy... Exchanged with an poor, old, unused d-link and all went fine.

I found a detail. If I attach OpenVPN to the WAN interface IP address (and not to one of the virtual IPs on the WAN interface) all trafic from clients work.

Thank you very much for the input. Okay, that makes sense as I have a perfectly fine connection. Maybe I should restart the router to confirm this 100% because the once restarted all routes will be lost. So, what are you thoughts about: "persist-key;persist-tun;resolv-retry infinite" Thanks,