Thanks, that's clearer. I'll do the redirecting bit, so if I decide to change to UDP later (unlikely, but you never know) it won't bite me.

Problem solved: reinstalled both ESXi machines (promisc mode on) reinstalled both VM pfSense (2.1beta i386) configured OVPN bridge (tap) first > works ok configured OVPN tunnel (tun) all working smoothly I should've done this from the begging, not trying to fix anything was broke. This topic can be closed. Thanks again

I'm looking to do this same thing.  I want all traffic in the new VLAN to go over the OpenVPN connection.  Jimp:  You mentioned setting DNS servers so they go over the VPN.  How would you do that?  Setup a rule that any connection to a certain DNS IP address uses the OpenVPN gateway? What if I also wanted any queries to certain websites to go over the OpenVPN connection, regardless of VLAN membership?  Thanks! EDIT:  What if I also wanted to set pfSense as an OpenVPN server for a separate connection?  Would this pose serious issues?

OpenVPN on client: Feb 18 16:34:31 openvpn[13124]: TCPv4_CLIENT link local (bound): [AF_INET]xx.xx.xx.xx Feb 18 16:34:31 openvpn[13124]: TCPv4_CLIENT link remote: [AF_INET]xx.xx.xx.xx:1197 Feb 18 16:34:31 openvpn[13124]: Peer Connection Initiated with [AF_INET]xx.xx.xx.xx:1197 Feb 18 16:34:32 openvpn[13124]: Initialization Sequence Completed Ping results: Packets: Sent = 101, Received = 69, Lost = 32 (31% loss), Approximate round trip times in milli-seconds: Minimum = 22ms, Maximum = 126ms, Average = 37ms OpenVPN on server: Feb 18 16:34:28 openvpn[11737]: Inactivity timeout (–ping-restart), restarting Feb 18 16:34:28 openvpn[11737]: SIGUSR1[soft,ping-restart] received, process restarting Feb 18 16:34:29 openvpn[11737]: NOTE: the current –script-security setting may allow this configuration to call user-defined scripts Feb 18 16:34:29 openvpn[11737]: Re-using pre-shared static key Feb 18 16:34:29 openvpn[11737]: Preserving previous TUN/TAP instance: ovpns1 Feb 18 16:34:29 openvpn[11737]: Listening for incoming TCP connection on [AF_INET]xx.xx.xx.xx:1197 Feb 18 16:34:31 openvpn[11737]: TCP connection established with [AF_INET]xx.xx.xx.xx:1765 Feb 18 16:34:31 openvpn[11737]: TCPv4_SERVER link local (bound): [AF_INET]xx.xx.xx.xx:1197 Feb 18 16:34:31 openvpn[11737]: TCPv4_SERVER link remote: [AF_INET]xx.xx.xx.xx:1765 Feb 18 16:34:31 openvpn[11737]: Peer Connection Initiated with [AF_INET]xx.xx.xx.xx:1765 Feb 18 16:34:32 openvpn[11737]: Initialization Sequence Completed As you can see, these logs show the initial connection but there is nothing after that.

solved my problem, many thanks  ;) .

UPDATE: After re-watching the video, I decided to delete the user I had before and re-created it. Everything worked like a charm after that! Any admins may mark this as solved.

Let me try to see if I understand you correctly. Which one is it: you want to replace IPsec with OpenVPN for a network topology consisting of 3 sites, each of which will be communicating directly with the other two, or you want to keep the current IPsec VPN setup, and just add a OpenVPN remote-access functionality (so that people can connect from e.g. home) to the main site, but you also want remote workers to be able to connect to LAN IPs at all three sites. In the first case,  keep in mind that you can't have a fully-routed topology and use both IPsec and OpenVPN at the same time. In the second scenario, you'd need to add IPsec P-2 entries for the OpenVPN roadwarrior subnet at both site-1 and site-3, and push appropriate routes to your OpenVPN clients (assuming you're not redirecting all their traffic to go via the VPN).

yes they do.

Just make one CA for each "class" of VPN. One just for the site-to-site. Separate ones for each remote access that has a different set of access restrictions. Trying to do a large structure and intermediates is just over-complicating it for very little, if any, benefit.

Thank you so much! :)

I think the netmask of the tunnel network needs to be /31 please give it a try. @cdc1975: Thanks for your help. ping from pfsense1 lan interface –-> pfsense2 lan-client OK ping from pfsense2 lan interface ---> pfsense1 lan-client OK ping from pfsense1 lan-client ---> pfsense 2 lan-client OK ping from pfsense2 lan-client ---> pfsense 1 lan-client OK From the pfsense1 or 2 is all ok! I can ping or ssh every machine in the 2 network. The problem is only when from a computer in one network i need to access to a computer in the other network. ping from a server in lan 1 --> to a server in lan 2 NOT OK ping from a server in lan 2 --> to a server in lan 1 NOT OK

Upgrading to snap shot solved this problem. 2.0.3-PRERELEASE (amd64) built on Sat Feb 9 21:12:53 EST 2013

The problem was what I was suspecting. I had to create a rule that did not use a static port for destinations with port 1194. I then moved it in front of the rest of the LAN to WAN NAT settings.

I have TUN working so will stick with this for now and will revisit when pfsense 2.1 is released.

Could you use 'client specific overrides' to give specific IP addresses to each user, then standard rules to restrict access?

In the Main Site OpenVPN Server Advanced box add: push "route 192.168.3.0 255.255.255.0" That will tell your OpenVPN road warriors about the route to East Coast. In the East Coast config, you will also need to tell it that the road warrior subnet (192.168.1.0/24) is reached across the IPsec link to Main - then East Coast can route/reply back to Road Warrior. I don't use IPsec, but I guess that will be easy. If you have restrictive firewall rules on OpenVPN or IPsec then you will need to modify those to pass packets to/from all 3 subnets.

@phil.davis: It should work. Once the OpenVPN tunnel establishes, the routing table at 21x.x.x.x will have an entry for 195.x.x.x/n that will send those packets across the tunnel. Similarly the routing table at 195.x.x.x will have an entry for 21x.x.x.x sending those packets across the tunnel. Once the user packets between 21x.x.x.x<->195.x.x.x are in the tunnel, they are encapsulated and encrypted inside OpenVPN packets. Routers on the real internet only see the OpenVPN tunnel endpoints as source/destination. It will be transparent to the users at either end. and internet routers can't see the details of the user packets encrypted inside the OpenVPN tunnel comms. Thanks Cheers  :)