My understanding is you need to ad additional phase 2 for the other subnet

Dropping a note here, as I did in your other thread: It's definitely a problem. I put a fix in 2.3 for it. https://redmine.pfsense.org/issues/6010 It's a fairly simple change, it may apply to 2.2.x directly, if not it's still simple to apply by hand if it's a show-stopper for you, though they are processed correctly at boot time as far as I can see, so adjusting them via ifconfig after creation should be OK for the time being. 2.3 will be out before too long. :-)

@cmb: That's 'ipsec statusall', no space in between, but that likely isn't going to be telling in this case. What does the output of "setkey -DP" show when it's not working and when it is? I'm thinking there's an ordering issue of some sort there. ** ipsec statusall (ipsec conected after reboot, no LAN ping from LAN subnet) [root@vpn-gualeguaychu ~]# ipsec statusall Status of IKE charon daemon (weakSwan 5.3.3, FreeBSD 10.1-RELEASE-p24, i386):   uptime: 3 minutes, since Mar 17 14:45:02 2016   worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 3   loaded plugins: charon unbound aes des blowfish rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey ipseckey pem openssl fips-prf xcbc cmac hmac curl attr kernel-pfkey kernel-pfroute resolve socket-default stroke vici updown eap-identity eap-sim eap-md5 eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap whitelist addrblock unity Listening IP addresses:   181.xxx.xxx.xxx   10.85.30.1 Connections:   bypasslan:  %any…%any  IKEv1/2   bypasslan:  local:  uses public key authentication   bypasslan:  remote: uses public key authentication   bypasslan:  child:  10.85.0.0/16|/0 === 10.85.0.0/16|/0 PASS     con1000:  181.xxx.xxx.xxx...201.xxx.xxx.xxx  IKEv1 Aggressive, dpddelay=10s     con1000:  local:  [gualeguaychu@osprera.org.ar] uses pre-shared key authentication     con1000:  remote: [201.xxx.xxx.xxx] uses pre-shared key authentication     con1000:  child:  10.85.0.0/16|/0 === 10.0.0.0/8|/0 TUNNEL, dpdaction=restart Shunted Connections:   bypasslan:  10.85.0.0/16|/0 === 10.85.0.0/16|/0 PASS Routed Connections:     con1000{4}:  ROUTED, TUNNEL, reqid 1     con1000{4}:  10.85.0.0/16|/0 === 10.0.0.0/8|/0 Security Associations (1 up, 0 connecting):     con1000[1]: ESTABLISHED 3 minutes ago, 181.xxx.xxx.xxx[gualeguaychu@osprera.org.ar]…201.xxx.xxx.xxx[201.216.208.113]     con1000[1]: IKEv1 SPIs: 51f33f634aae57e2_i* 6761851f86de30b5_r, pre-shared key reauthentication in 7 hours     con1000[1]: IKE proposal: 3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024     con1000{2}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: cbfd4079_i 046b1ec2_o     con1000{2}:  AES_CBC_256/HMAC_MD5_96, 273639 bytes_i (1235 pkts, 0s ago), 316104 bytes_o (1283 pkts, 0s ago), rekeying in 19 minutes     con1000{2}:  10.85.0.0/16|/0 === 10.0.0.0/8|/0 [root@vpn-gualeguaychu ~]# ** setkey -DP (ipsec conected after reboot, no LAN ping from LAN subnet) [root@vpn-gualeguaychu ~]# setkey -DP 10.0.0.0/8[any] 10.85.0.0/16[any] any         in ipsec         esp/tunnel/201.xxx.xxx.xxx-181.xxx.xxx.xxx/unique:1         created: Mar 17 14:45:29 2016  lastused: Mar 17 14:52:15 2016         lifetime: 2147483647(s) validtime: 0(s)         spid=6 seq=3 pid=91411         refcnt=1 10.85.0.0/16[any] 10.85.0.0/16[any] any         in none         created: Mar 17 14:45:52 2016  lastused: Mar 17 14:45:52 2016         lifetime: 2147483647(s) validtime: 0(s)         spid=10 seq=2 pid=91411         refcnt=1 10.85.0.0/16[any] 10.0.0.0/8[any] any         out ipsec         esp/tunnel/181.xxx.xxx.xxx-201.xxx.xxx.xxx/unique:1         created: Mar 17 14:45:29 2016  lastused: Mar 17 14:52:16 2016         lifetime: 2147483647(s) validtime: 0(s)         spid=5 seq=1 pid=91411         refcnt=1 10.85.0.0/16[any] 10.85.0.0/16[any] any         out none         created: Mar 17 14:45:52 2016  lastused: Mar 17 14:45:52 2016         lifetime: 2147483647(s) validtime: 0(s)         spid=9 seq=0 pid=91411         refcnt=1 [root@vpn-gualeguaychu ~]# then, ipsec stop, ipsec start: (ipsec conected, PING ok to LAN from LAN subnet) ipsec statusall [root@vpn-gualeguaychu ~]# ipsec statusall Status of IKE charon daemon (weakSwan 5.3.3, FreeBSD 10.1-RELEASE-p24, i386):   uptime: 12 seconds, since Mar 17 14:54:26 2016   worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 3   loaded plugins: charon unbound aes des blowfish rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey ipseckey pem openssl fips-prf xcbc cmac hmac curl attr kernel-pfkey kernel-pfroute resolve socket-default stroke vici updown eap-identity eap-sim eap-md5 eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap whitelist addrblock unity Listening IP addresses:   181.xxx.xxx.xxx   10.85.30.1 Connections:   bypasslan:  %any…%any  IKEv1/2   bypasslan:  local:  uses public key authentication   bypasslan:  remote: uses public key authentication   bypasslan:  child:  10.85.0.0/16|/0 === 10.85.0.0/16|/0 PASS     con1000:  181.xxx.xxx.xxx...201.xxx.xxx.xxx  IKEv1 Aggressive, dpddelay=10s     con1000:  local:  [gualeguaychu@osprera.org.ar] uses pre-shared key authentication     con1000:  remote: [201.xxx.xxx.xxx] uses pre-shared key authentication     con1000:  child:  10.85.0.0/16|/0 === 10.0.0.0/8|/0 TUNNEL, dpdaction=restart Shunted Connections:   bypasslan:  10.85.0.0/16|/0 === 10.85.0.0/16|/0 PASS Routed Connections:     con1000{1}:  ROUTED, TUNNEL, reqid 1     con1000{1}:  10.85.0.0/16|/0 === 10.0.0.0/8|/0 Security Associations (1 up, 0 connecting):     con1000[1]: ESTABLISHED 12 seconds ago, 181.xxx.xxx.xxx[gualeguaychu@osprera.org.ar]…201.xxx.xxx.xxx[201.216.208.113]     con1000[1]: IKEv1 SPIs: 1d1e895fe7c58369_i* 0134c120391e748b_r, pre-shared key reauthentication in 7 hours     con1000[1]: IKE proposal: 3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024     con1000{2}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c8dbde05_i 04d2c445_o     con1000{2}:  AES_CBC_256/HMAC_MD5_96, 17097 bytes_i (124 pkts, 0s ago), 30560 bytes_o (122 pkts, 0s ago), rekeying in 22 minutes     con1000{2}:  10.85.0.0/16|/0 === 10.0.0.0/8|/0 [root@vpn-gualeguaychu ~]# ** setkey -DP [root@vpn-gualeguaychu ~]# setkey -DP 10.85.0.0/16[any] 10.85.0.0/16[any] any         in none         created: Mar 17 14:54:27 2016  lastused: Mar 17 14:56:20 2016         lifetime: 2147483647(s) validtime: 0(s)         spid=14 seq=3 pid=44444         refcnt=1 10.0.0.0/8[any] 10.85.0.0/16[any] any         in ipsec         esp/tunnel/201.xxx.xxx.xxx-181.xxx.xxx.xxx/unique:1         created: Mar 17 14:54:27 2016  lastused: Mar 17 14:56:19 2016         lifetime: 2147483647(s) validtime: 0(s)         spid=18 seq=2 pid=44444         refcnt=1 10.85.0.0/16[any] 10.85.0.0/16[any] any         out none         created: Mar 17 14:54:27 2016  lastused: Mar 17 14:56:20 2016         lifetime: 2147483647(s) validtime: 0(s)         spid=13 seq=1 pid=44444         refcnt=1 10.85.0.0/16[any] 10.0.0.0/8[any] any         out ipsec         esp/tunnel/181.xxx.xxx.xxx-201.xxx.xxx.xxx/unique:1         created: Mar 17 14:54:27 2016  lastused: Mar 17 14:56:20 2016         lifetime: 2147483647(s) validtime: 0(s)         spid=17 seq=0 pid=44444         refcnt=1 [root@vpn-gualeguaychu ~]#

Thanks for your reply. We upgrade from version 2.2.3 -> 2.2.6 Not at all. There is any rule in Firewall->Nat, Outbound tab for IPSEC Interface. As I said in the original post. This configuration was working perfectly BEFORE the upgrade. After that my counterpart at the other side of the tunnel start complain that I wasn't use the right IP Address to access his network. The problem was solved changing the Local Network config at phase 2, changing the subnet /29 just to a single IP address. We have to do it at both sides of the tunnel, ofcourse. The firewall at the other side of the tunnel is a Fortinet, and we had a hard time making the tunnel work in the past (with PFSense 2.2.3), but when it start to work it was rock solid. Looking at: 2.2.3 - release notes 2.2.6 - release notes I notice that StrongSwan upgrade from version 5.3.2 in PFSense 2.2.3 to version 5.3.5 in PFSense 2.2.6. Pheraps there is some change there.

Not really sure, but other thing to try….... CLIENTE IPSEC Phase 2 proposal (SA/Key Exchange) ONLY CHECK Encryption algorithms AES / Blowfish / 3DES / CAST128 / DES Hash algorithms ONLYE CHECK MD5 and SHA1 have to try it some more days...........

Check your outbound NAT and make sure you don't have a rule that might be catching the traffic (e.g. source = any)

Solved by adding multiple P2s, one for LAN, one for OPT.

What you actually want is the client on the same broadcast domain, not (just) the same IP subnet. You can use a mobile IPsec tunnel network that's a subset of your LAN, if you add proxy ARP on LAN for that subset, but that won't get the clients on the same broadcast domain. No mobile IPsec clients support that.

Are you using multiple gateways?  What do your rules look like on your interfaces?  Allow all on each?

Issue solved. You do not have to enter user/pass in user manager, but in sahred key section…

With me is fresh install of 2.2.6 - so no upgrade….... IkeV2 is not an option as V2 is not suppported by  older 2.0.X boxes :( Good you do not have the problems...I guess we will have to upgrade too...Just wanted to avoid it if possible.

OK just limiters. I would disable the rule you added, turn logging on on the main pass rule, try to open connections across the VPN, and see what they logs say. Hmm. Limiters. I don't see anything that should do it but you might be hitting the 2.2.X limiter bug. Also disable the rule you added and try it without the limiters set.

Oh sorry last time i did not  realize that you try to connect to a mobile android For my android 5.1.1 with strongswan app  as a road warrior it looks like ( important part;  leftsub 0.0.0.0) conn con3 fragmentation = yes keyexchange = ikev2 reauth = yes forceencaps = no mobike = yes rekey = yes installpolicy = yes type = tunnel dpdaction = clear dpddelay = 10s dpdtimeout = 60s auto = add left = xxx.xxx.xxx.xxx right = %any leftid = "C=xxx, ST=xxxx, L=xxxx, O=xxxx, E=postmaster@xxx, CN=xxxxxx" ikelifetime = 28800s lifetime = 3600s rightsourceip = 192.168.123.0/24 ike = aes256-sha512-modp2048! esp = aes256-sha512! eap_identity=%identity leftauth=pubkey rightauth=eap-tls leftcert=/var/etc/ipsec/ipsec.d/certs/cert-3.crt leftsendcert=always rightca="/C=xxx/ST=xxx/L=xxx/O=xxx/emailAddress=postmaster@xxx/CN=xxx-internal-ca/" leftsubnet = 0.0.0.0/0 But maybe just remove all ipsec config and restart pfsense, i had this once wit a hanging ipsec tunnel… regards max

I need to monitor the ipsec tunnel on Nagios using snmp or SSH.

Hm, might be some edge case there where somehow the SPD isn't populated. If strongswan's running at all, it'll have that populated though. I can't think of any circumstance where that could occur. Definitely would be interested in steps to replicate if you come across something. If IPsec were disabled for any period of time during troubleshooting, that could explain it.

Not installing NAT reflection rules for a port range > 500 Something is trying to get from the internal LAN through the WAN interface to connect in the DMZ or LAN homed Servers and there are no rules for NAT reflection (Hairpin NAT) could this be a problem too? IPSEC: One or more IPsec tunnel endpoints has changed its IP. Refreshing. Is there in the other LAN perhaps something likes an enabled DHCP Server that is giving new IP addresses to servers or other devices that should be sorted more with static IP addresses?