Well… (feeling kinda stupid) :P I got as far as step 2 and it started working like expected. I haven't had to reboot PFSense devices in ages and didn't occur to me. In my defense, they were also in production use so was not convenient at the time. Problem solved IPSec had something left over after disabling tunnels that a reboot resolved. Thanks Marvosa...

@marvosa: Need to clarify some info: Your diagram shows "OpenVPN Tunnel Network: 10.0.10.0/24" and "Subnet to pfSense3: 10.0.10.8/30".  Please clarify what you meant because those networks overlap. When you say "I have a remote site connected with OpenVPN Peer to Peer (SSL/TLS) working" you never specified what was connected. I can only assume from your diagram that you meant PFsense 1 and PFsense 3 are connected and that each side can communicate with the other side's LAN, but please verify my assumption is correct. On PFsense 2, is there a typo or is 172.16.10.1/26 really a WAN interface? Why isn't it a LAN interface?  I would imagine 172.16.20.0/26 cannot communicate with 172.16.10.0/26 because there is no return route back to 172.16.20.0/26 on PFsense 2.  Although, I'm not even sure that's possible because it's a WAN interface and being NAT'd… someone else chime in if they know for sure you need a return route to 172.16.20.0/26 on the cisco. Remember Post your server1.conf from PFsense 1 and client1.conf from PFsense 3. pfSense1 Site2Site (PKI) dev ovpns2 dev-type tun tun-ipv6 dev-node /dev/tun2 writepid /var/run/openvpn_server2.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp cipher AES-256-CBC up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local TRIMMED-PUBLIC-IP tls-server server 10.0.10.0 255.255.255.0 client-config-dir /var/etc/openvpn-csc ifconfig 10.0.10.1 10.0.10.2 tls-verify /var/etc/openvpn/server2.tls-verify.php lport 1195 management /var/etc/openvpn/server2.sock unix ca /var/etc/openvpn/server2.ca cert /var/etc/openvpn/server2.cert key /var/etc/openvpn/server2.key dh /etc/dh-parameters.1024 tls-auth /var/etc/openvpn/server2.tls-auth 0 route 172.16.20.0 255.255.255.192 route 172.16.20.64 255.255.255.192 route 192.168.0.0 255.255.255.0 push "route 172.16.0.0 255.255.248.0" push "route 172.16.10.0 255.255.255.192" push "route 10.2.6.0 255.255.255.0" push "route 10.2.31.0 255.255.255.0" push "route 10.31.10.0 255.255.255.0" push "route 10.31.112.0 255.255.255.0" push "route 10.31.253.0 255.255.255.0" push "route 10.32.253.0 255.255.255.0" push "route 10.252.130.0 255.255.255.0" push "route 10.252.144.0 255.255.255.0" push "route 10.252.252.0 255.255.255.0" push "route 10.253.1.192 255.255.255.255" push "route 10.253.252.0 255.255.255.0" pfSense3 (Client) dev ovpnc1 dev-type tun dev-node /dev/tun1 writepid /var/run/openvpn_client1.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp cipher AES-256-CBC up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local TRIMMED-PUBLIC-IP tls-client client lport 0 management /var/etc/openvpn/client1.sock unix remote TRIMMED-REMOTE-IP 1195 ifconfig 10.0.10.2 10.0.10.1 ca /var/etc/openvpn/client1.ca cert /var/etc/openvpn/client1.cert key /var/etc/openvpn/client1.key tls-auth /var/etc/openvpn/client1.tls-auth 1 Also here is the CSO (-csc) file for that client ifconfig-push 10.0.10.10 10.0.10.9 iroute 172.16.20.0 255.255.255.192 USING Site2Site 12:00:41.556303 IP 192.168.0.47.38007 > 10.31.10.89.33438: UDP, length 24 12:00:41.628250 IP 192.168.0.47.38007 > 10.31.10.89.33439: UDP, length 24 12:00:41.699052 IP 192.168.0.47.38007 > 10.31.10.89.33440: UDP, length 24 12:00:41.770609 IP 192.168.0.47.38007 > 10.31.10.89.33441: UDP, length 24 12:01:55.579807 IP 192.168.0.47.38022 > 10.31.10.89.33441: UDP, length 24 12:02:00.580990 IP 192.168.0.47.38022 > 10.31.10.89.33442: UDP, length 24 12:02:05.581638 IP 192.168.0.47.38022 > 10.31.10.89.33443: UDP, length 24 12:02:10.582314 IP 192.168.0.47.38022 > 10.31.10.89.33444: UDP, length 24 USING RoadWarrior 11:35:41.019829 IP 10.0.8.202.37905 > 10.31.10.89.33435: UDP, length 24 11:35:41.182282 IP 10.0.8.202.37905 > 10.31.10.89.33436: UDP, length 24 11:35:41.253157 IP 10.0.8.202.37905 > 10.31.10.89.33437: UDP, length 24 11:35:41.324107 IP 10.0.8.202.37905 > 10.31.10.89.33438: UDP, length 24 11:37:07.139149 IP 10.31.253.2.46027 > 10.31.10.89.33438: UDP, length 24 11:37:07.281083 IP 10.31.253.2.15414 > 10.31.10.89.33439: UDP, length 24 11:37:07.351882 IP 10.31.253.2.3381 > 10.31.10.89.33440: UDP, length 24 11:37:07.422730 IP 10.31.253.2.23474 > 10.31.10.89.33441: UDP, length 24

This mysteriously started working.  The only thing I can think of is that I a reboot of my Ubuntu Laptop or pfSense server fixed the issue.

Fair enough.  Like I said, though, I am literally the only person who has access to this VPN.  Thanks, I think I will figure out how to secure access from the VPN subnet just to be safe, and remove the NAT rule…

It worked! Thank you for your patience! I didn't even think to change the "LAN" part of that config. I was kind of assuming that once you're VPN'd in, you're part of the LAN.

ah yes… I have later forgot/overseen the 1st change which calls the update routine... --- /usr/local/www/system_crlmanager.php.orig 2013-04-12 16:31:46.000000000 +0200 +++ /usr/local/www/system_crlmanager.php 2013-11-29 23:21:22.000000000 +0100 @@ -107,6 +107,7 @@ } if ($act == "exp") { + crl_update($thiscrl); $exp_name = urlencode("{$thiscrl['descr']}.crl"); $exp_data = base64_decode($thiscrl['text']); $exp_size = strlen($exp_data); @@ -580,11 +581,9 @@ - [" alt="" width="17" height="17" border="0" />](system_crlmanager.php?act=exp&id=<?=$tmpcrl['refid'];?>) - [" alt="" width="17" height="17" border="0" />](system_crlmanager.php?act=edit&id=<?=$tmpcrl['refid'];?>)

Unless you instruct OpenVPN to push a default gateway, only the network you specify when you setup the tunnel will be accessible through the VPN. Since I'm with XS4all I have WebTV and native IPv6. So I'm pushing routes to the webtv network in addition to the local network. All other traffic remains outside the tunnel. Since you want to send all traffic through the tunnel you have to push a IPv4 default gsteway. You can do this in the tunnel setup. To have IPv6 everywhere I push a IPv6 default gateway always. But as you do not have IPv6, don't worry about it. The only thing you have to do on the PFS box is to make sure that all traffic is forwarded through the other OpenVPN tunnel. In my ignorence I assumed it was an IPsec tunnel. As said, with an Atom processor without HW encryption I get 60Mbps.

Completely reinstalled pfSense and what do you know?  It's working. Hypotheses: Corruption of original installation and/or Using older version of OpenVPN Client Export pacakge and/or Some other installed package caused a problem (have installed this fairly lean on this occasion). Thanks to all for your help.  I'm going to snapshot this virtual machine while it's working!!!

Not sure, was thinking would of been nice, but if it really doesn't offer anything over self signed certs, then no reason for me to do it! I have been revising my network and consolidating all admin tools under a domain and using https on everything and so thought why not use the cert on VPN since i have it. I clearly have had the "headache" part of it so far! Appreciate the response.

You have always been able to run OpenVPN and IPsec at the same time. Just not for conflicting networks. You can run them both to different places, but you can't have them both cover the exact same route/subnets on both ends of a tunnel. OK: x.x.a.0/24 to x.x.b.0/24 - OpenVPN x.x.a.0/24 to x.x.c.0/24 - IPsec Not OK: x.x.a.0/24 to x.x.b.0/24 - OpenVPN x.x.a.0/24 to x.x.b.0/24 - IPsec