Ok thanks. I'll give it a whirl!

I've done some more testing with this and I'm a bit confused by what I am seeing.  When I ping 192.168.1.20 from the pfsense console on 192.168.1.10, the pings go through and I see the traffic has been encapsulated when I do a packet capture.  If I try to ping from a host behind the firewall, I see that the ICMP traffic has not been encapsulated.  A traffic capture on the peer shows the ping, however, the reply does not show as being transmitted.  The firewall log shows that the echo request came in on the WAN, not IPsec. I believe the issue here is that the pings are not being encapsulated and if I can get that worked, GRE will also come alive.  I tried dumping the pfsense built IPsec.conf for a simpler file, however, the traffic is still not flowing as expected. It seems like this is something that should just work, so I'm a bit baffled that it is not.  Does anyone else have transport mode working in this manner?

I Solved looking at and playing with this things  : IN IPSEC - MOBILE CLIENT TAB ->Network configuration for Virtual Address Pool , using a totally diferent subnet …. For example, if your LAN subnet is 192.168.0.X  then use 10.1.1.0 or wharever... IN Windows 10… set "Use default gateway on remote NETWORK" look at this on network connections... Properties ... ip v4 tcp/ip  properties... advanced...  IP Settings Tab Hope this helps…. I spend a lot of time with this... Best Regards...

Got answer for Apple (for iOS not macOS ticket, Q.E.D. :)). For IKEv2 on the iOS device to use the configured DH groups in Child Rekey, you will need to set the Enable Perfect Forward Secrecy option in the Apple Configurator application. Had not checked that, facepalm. For test have set Group 1 for 20 min rekeying, Group 2 for 10 min rekeying. On connect phase 1: charon 05[CFG] <31> selected proposal: IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/ECP_384 charon 05[CFG] <31> configured proposals: IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/ECP_384 charon 05[CFG] <31> received proposals: IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/ECP_384 On connect phase 2: charon 11[CFG] <con1|37> selected proposal: ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ charon 11[CFG] <con1|37> configured proposals: ESP:AES_CBC_256/HMAC_SHA2_256_128/ECP_384/NO_EXT_SEQ charon 11[CFG] <con1|37> received proposals: ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ</con1|37></con1|37></con1|37> On rekey phase 2: charon 10[CFG] <con1|32> selected proposal: ESP:AES_CBC_256/HMAC_SHA2_256_128/ECP_384/NO_EXT_SEQ charon 10[CFG] <con1|32> configured proposals: ESP:AES_CBC_256/HMAC_SHA2_256_128/ECP_384/NO_EXT_SEQ charon 10[CFG] <con1|32> received proposals: ESP:AES_CBC_256/HMAC_SHA2_256_128/ECP_384/NO_EXT_SEQ charon 10[CFG] <con1|32> proposal matches charon 10[CFG] <con1|32> selecting proposal: charon 10[ENC] <con1|32> parsed CREATE_CHILD_SA request 2 [ N(REKEY_SA) SA No KE TSi TSr ]</con1|32></con1|32></con1|32></con1|32></con1|32></con1|32> On rekey phase 1: charon 15[CFG] <con1|31> selected proposal: IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/ECP_384 charon 15[CFG] <con1|31> configured proposals: IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/ECP_384 charon 15[CFG] <con1|31> received proposals: IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/ECP_384 charon 15[CFG] <con1|31> proposal matches charon 15[CFG] <con1|31> selecting proposal: charon 15[IKE] <con1|31> IKE_SA con1[32] state change: CREATED => CONNECTING charon 15[IKE] <con1|31> 192.168.10.146 is initiating an IKE_SA</con1|31></con1|31></con1|31></con1|31></con1|31></con1|31></con1|31> Seems to be rekeying now. ``` ./iperf3 -c IPADDR -P 4 -f m -d -t 22 -O 2 -i 1 However charon 10[CFG] <con1|37>lease 172.23.152.1 by 'ikemaster' went offline charon 10[IKE] <con1|37>IKE_SA con1[37] state change: DELETING => DESTROYING charon 10[IKE] <con1|37>IKE_SA deleted charon 10[ENC] <con1|37>parsed INFORMATIONAL response 2 [ ] charon 10[NET] <con1|37>received packet: from 192.168.10.146[4500] to 192.168.10.100[4500] (88 bytes) charon 10[NET] <con1|37>sending packet: from 192.168.10.100[4500] to 192.168.10.146[4500] (88 bytes) charon 10[ENC] <con1|37>generating INFORMATIONAL request 2 [ D ] charon 10[IKE] <con1|37>sending DELETE for IKE_SA con1[37] charon 10[IKE] <con1|37>IKE_SA con1[37] state change: ESTABLISHED => DELETING charon 10[IKE] <con1|37>deleting IKE_SA con1[37] between 192.168.10.100[XXXX]…192.168.10.146[ikemaster] charon 10[IKE] <con1|37>activating IKE_DELETE task charon 10[IKE] <con1|37>activating new tasks charon 10[IKE] <con1|37>queueing IKE_DELETE task</con1|37></con1|37></con1|37></con1|37></con1|37></con1|37></con1|37></con1|37></con1|37></con1|37></con1|37></con1|37></con1|37> it seems that pfSense itself queues and executes IKE_DELETE and it happens both on macOS and MSW.

I also ran into this issue as my macOS 10.12.x machines worked fine and an older pair of machines running 10.11.6 could not connect to the VPN. I tried IKEv2, but could not get that to work so I started to fiddle with some additional settings and found that in 'IPsec->Advanced Settings' I had enabled 'IP Compression' and 'Enable Cisco Extensions' (Unity plugin). After disabling both and restarting the IPsec service in pfSense my 10.11.6 machines are able to make the IPsec connection. So maybe the cause of the mentioned Phase 1 chatter and failing exchange is in the 'Unity plugin' as it is related to Cisco extensions and the macOS Client for IPsec is specifically labeled 'Ciso IPsec'. My configuration settings : Mobile Clients Enable IPSsec Mobile Client Support IKE Extensions -> Enable Extended Authentication User Authentication -> Local Database Group Authentication -> system Client Configuration Virtual Address Pool -> checked any private address range Virtual IPv6 Address Pool -> not checked Network List -> not checked Save Auth Password -> checked DNS Default Domain -> not checked Split DNS -> not checked DNS servers -> not checked WINS Servers -> not checked Phase2 PFS Group -> not checked Login Banner -> not checked IPsec Tunnels -> Mobile Client General Information Key Exchange version -> IKEv1 Internet Protocol -> IPv4 Interface -> WAN Description -> Mobile VPN Phase 1 Proposal (Authentication) Authentication Method -> Mutual PSK + Auth Negotiation mode -> Aggressive (Main does not work) My Identifier -> My IP address Peer Identifier -> User distinguished name [@domain] Pre-Shared Key -> some strong password Phase 1 Proposal (Algorithms) Encryption Algorithm -> AES 256 bits Hash Algorithm -> SHA256 DH Group -> 14 Lifetime (Seconds) -> 86400 Advanced Options Disable Key -> not checked Responder Only -> not checked NAT Traversal -> Force Dead Peer Detection -> checked Delay -> 10 Max Failures -> 5 Phase 2 General Information Mode -> Tunnel IPv4 Local Network -> LAN subnet NAT/BINAT translation -> None Description -> Only Internal Traffic Mobile VPN Phase 2 Proposal Protocol -> ESP Encryption Algorithms -> AES 128 bits Hash Algorithms -> SHA1 PFS key group -> off Lifetime -> 28800

Any ideas guys ? A reminder for the above post , We want traffic from site1 to site2 to appear from a single /32 IP . Thanks a lot

The problem appears to be solvable with BINAT in the IPsec phase 2. https://doc.pfsense.org/index.php/NAT_with_IPsec_Phase_2_Networks Under local network I have put my LAN addresses. In the NAT/BINAT configuration I have put my external IP, which the other end sees. In remote network I have put the public /30 addresses. Something was not entirely right in the other end, will have to wait for them to get back.

Followed this How-To and now have a working site to site, IPSec VPN. https://doc.pfsense.org/index.php/VPN_Capability_IPsec Our issue that was preventing it from working is that AT&T blocks certain traffic required for the tunnel to operate properly. Will probably be exploring OpenVPN, Hub and Spoke topology in the next day or so and if all goes well, replace this site to site.

There's something wrong with firewall rule 3 on the pfsense side. The protocol should be AH (that is protocol 51) and not TCP port 51 (which is… nothing) I configured: And new rule 3: Action: Pass Disabled: Unchecked Interface: WAN TCP/IP Version: IPv4 Protocol: AH Source: any Destination: WAN address Description: IPsec Authentication Headers | PASS

Ok, let me take a look at the ipsec command.  Thanks

Did you restore an older ipsec section of config to a newer version? The upgrade code will usually add those sorts of things for you automatically, but only if the configuration is upgraded as a whole. To be missing something like that, you had to have imported sections of an old config into a new system which won't work. Try restoring a 2.1.x config.xml backup from just before the upgrade in full and then see if they are there.