That cannot be directly achieved with anything. Something must distinguish the remote networks. You can't solve that conflict locally. In this case, if your side has the overlap, one or both of the remote sides must perform NAT to mask the true subnet so that your side does not have a conflict. If you have pfSense on both sides, this is easily achieved with IPsec (Phase 2 NAT) or OpenVPN (1:1 NAT or outbound NAT). If the remote ends are out of your control, then you can't solve the problem with a single unit. You'd have to have two separate firewalls, one for each tunnel, and perform NAT on one or both before the traffic exits to the local network.

@Derelict: Yup. Looks like a bug in Apple's implementation. Interestingly, it does not occur if you use a profile to configure the IPsec connection. The factory versions of pfSense have a profile exporter package or you can use the Profile Manager in OS X Server (macOS Server). There is a bug open with Apple. No feedback on it in a few weeks. This also occurred 10.11.X. Sorry to hear it is still present in 10.12.X. I haven't had time to test it yet. I tried the ipsec-profile-wizard and it didn't like the import I'm getting "The 'VPN Service' payload could not be installed. The VPN service could not be created." If I install my certs by hand and setup the vpn connection IKEv2 works fine, no disconnects on my iPhone or iPad away from home. My IPsec config :- <ipsec><client><enable></enable> <user_source>Local Database</user_source> <group_source>none</group_source> <pool_address>172.16.9.0</pool_address> <pool_netbits>24</pool_netbits> <dns_domain>XXXX XXXX.net</dns_domain> <dns_server1>172.16.1.1</dns_server1></client> <logging><dmn>1</dmn> <mgr>1</mgr> <ike>1</ike> <chd>1</chd> <job>1</job> <cfg>1</cfg> <knl>1</knl> <net>1</net> <asn>1</asn> <enc>1</enc> <imc>1</imc> <imv>1</imv> <pts>1</pts> <tls>1</tls> <esp>1</esp> <lib>1</lib></logging> <uniqueids>never</uniqueids> <phase1><ikeid>1</ikeid> <iketype>ikev2</iketype> <interface>wan</interface> <protocol>inet</protocol> <myid_type>fqdn</myid_type> <myid_data>vpn.xxxxxxxxxx.net</myid_data> <peerid_type>any</peerid_type> <peerid_data></peerid_data> <encryption-algorithm><name>aes</name> <keylen>256</keylen></encryption-algorithm> <hash-algorithm>sha256</hash-algorithm> <dhgroup>14</dhgroup> <lifetime>28800</lifetime> <pre-shared-key></pre-shared-key> <private-key></private-key> <certref>590e07927b298</certref> <caref></caref> <authentication_method>eap-mschapv2</authentication_method> <nat_traversal>on</nat_traversal> <mobike>on</mobike> <dpd_delay>10</dpd_delay> <dpd_maxfail>5</dpd_maxfail></phase1> <phase2><ikeid>1</ikeid> <uniqid>58ecc9de19c3f</uniqid> <mode>tunnel</mode> <reqid>1</reqid> <localid><type>network</type> <address>0.0.0.0</address> <netbits>0</netbits></localid> <protocol>esp</protocol> <encryption-algorithm-option><name>aes</name> <keylen>auto</keylen></encryption-algorithm-option> <hash-algorithm-option>hmac_sha256</hash-algorithm-option> <hash-algorithm-option>hmac_sha384</hash-algorithm-option> <hash-algorithm-option>hmac_sha512</hash-algorithm-option> <pfsgroup>0</pfsgroup> <lifetime>3600</lifetime></phase2> <mobilekey><ident>xxxxxx</ident> <type>EAP</type> <pre-shared-key>xxxxxx</pre-shared-key></mobilekey></ipsec>

Once I managed to get it to work by using a "default route" as my local network. However it gave different results depending on different versions of OSX and in how the existing routes.. What I have read it looks like PfSense will not be able to accomplish what I want to do here so I'm currently looking at other options.

Are you saying you expect AWS to transit your office(s) internal "WAN" traffic thought AWS?

It's up to the client to decide what to send. There is no mechanism in that protocol to inform the clients what subnets are available. The client has to define that itself.

IPsec is designed to prevent exactly this. You cannot simply "route" throug an IPsec-Tunnel. It is possible to circumvent this with multiple phase2 configs on ALL endpoints (which assumes, that you are allowed to do what you are trying, which it does not sounds like), but if you have to ask here on how to do that, it is likely to blow up in your face one way or the other. TL;DR: "Don't."

How and what do you ping? Do you ping via the gui of pfSense (Diagnostics->Ping) or do you use a computer behind the pfSenses? Do you ping the pfSense itself or a computer behind the pfSense? Do you see blocked packets in the firewall log (Status -> System Logs -> Firewall -> Normal View)? If yes, by what rule are the packets blocked? You can also use Diagnostics -> Packet Capture to see if icmp packets get in and out of both pfSenses

I don’t know exactly what happend, but now I can reach the internet and my LAN host with the correct setting. But still cannot resolve FQDN within the LAN. It doesn’t matter if I fill in lists of DNS servers or a search domain in pfSense or locally on my Mac. So I think now, it’s a DNS issue, but I don’t have any clue to resolve this.

Was currious if the aws wizard package was ever going to include the new zones.

Thanks Derelict  :D Will try that when we change ISP, I'll post results when I've tried.

next time, check to see if you have 0 bytes in one direction.

i frequently face this same identical issue, bytes one direction, but zero bytes opposite direction.  its reversed on the opposite pfsense.  this happens on a pfsense has has 26 or so IPSec tunnels, and just 1 tunnel will do this, the other 19 are functioning normally. sometimes it self recovers, sometimes this will go on for hours (effectively killing the tunnel and traffic from clients) until i massage it back online. i have not been able to figure out the root cause.

I was struggling for more than one week to make IPSec for mobile clients to work (only Android natively worked) and disabling "Provide a list of accessible networks to clients". I don't know if it's a bug or a feature, but disabling "Provide a list of accessible networks to clients" works on 2.4-BETA too.

@Derelict: I would use much longer IKE (P1) and ipsec (P2) lifetimes. Something like 86400/28800 should be more than sufficient. Most IPsec incompatibilities occur during re-key. Why make it re-key far more often than is necessary? Yea, 99% of problems occurs when re-keying. About the lifetimes I think you'd have to ask Netgate support since they provided the config. But personally, I will try to use longer lifetimes.

solved! In Interfaces->wan i set MTU to 1450 and everything work. Thanks anyway

Hello, I have a similar problem with 2.3.3 version, on pfsense 2.1.5 works fine.