Thanks heaps!! that worked perfectly! ;D

NAT has nothing to do with it. NATing IPsec connections is possible, but it does nothing for this scenario. It'd have to be routed in a means that isn't currently supported with IPsec. Might be possible with MLPPP over OpenVPN.

@filnko: Have you tried today's snapshots? There have been some recent problems with IPsec under 2.2 Sure enough, one more reboot - did it.  That's exactly what seems to have cured my issue, for whatever reason the NAT statement solved itself after a second reboot. THANK YOU.

At both ends I have allow all rules for IPv4 and IPv6 traffic. From the PBX I can ping the phone, and reach it's web interface. Didn't test from the clients pc on main office Side yet though. Can try that tomorrow.

it is the field "Peer identifier" select  "IP adress" and enter Remote ID

i have found the solution. The hint in this topic was a great help regarding the NAT. After doing as he advised, it worked straight away https://forum.pfsense.org/index.php?topic=81573.0

You can achieve this with either a dual-circuit connection (usually fairly expensive) or by updating DNS records. I don't think PFSense has the built-in functionality to update the DNS records if one WAN is down (please feel free to correct me), so you could use a provider like DNSMadeEasy and their DNS Failover. I think you would need to create a gateway group and use it for the IPsec interface. [EDIT] Apparently the DynDNS can use a gateway group too so no need for the likes of DNSMadeEasy. @jimp: It should work fine though for pfSense to pfSense you need both the IPsec tunnel set to a failover gateway group and a DynDNS entry set to the same failover gateway group, and then use that dyndns host as the remote peer address for the other side. Then when WAN1 fails to WAN2, the dyndns IP changes, so the far side knows to accept the new peer, and that's where IPsec will start connecting from.

In the local network part of the phase 2, put Address and 10.10.10.210. Directly underneath that, put the NAT address to show the other side, 172.16.199.1. For the remote network, if you need to reach all of 10/8, put that, otherwise put in the IP address they gave, 10.120.0.32

L2TP on its own is only an unencrypted tunneling protocol.

For your applications, TINC is better - But a pfsense openvpn client with a TAP interface can do it. I really only use openvpn for "road warrior" type configurations on end clients. I think thats what it does best. But it is flexible and if you handle routing correctly you can get what you want from it.

Logs? Look at the gateway and gateway monitoring on both sides of the tunnel, apinger might be an issue–-