For anyone interested, I have solved the problem!

I thought this was the last error message being logged before the client disconnected, however, due to an issue with my log server I just didn't see the rest of the logs.

The issues was with RADIUS accounting. My RADIUS server was not accepting the accounting messages, so I just had to switch the server to authentication only.

I'm have some problem, you have solution?

Thank you

Maybe I could ask the question in a different way …

The packets from the remote branch get to me over IPSec.  I then pass them to the 3rd party via IPSec also.

At what point does NAT kick in ?  Do these packets get passed back onto the IPSec to the 3rd party having been NAT'ed or are they unNAT'ed ?

If they are unNaT'ed, then I know that the 3rd party will need to add the branch office IP address range to the phase 2 setting on their firewall.  If it is NAT'ed as soon as it hits my firewall initially, then does it masquerade as my LAN address or some other IP subnet that I don't know.  Do the branch office packets actually go anywhere near my LAN or do they stay within the logical realm of IPSec, as per the firewall rules tabs ?

Hope that makes sense to someone.
Thanks

I took another look at setting up remote access last night and was able to get it to work.

The problem I was having is that when I went to install the certificate on the laptop I was using certmgr.msc to just install it on the user side.  When I used the MMC console and specified the local machine and then installed the certificate (which also puts it on the personal side as well), I was able to make the connection without a problem.  I think that should be highlighted in any guides that this must be done.  I think a lot of people could make a similar mistake thinking "oh I just have to install a certificate, I know how to do that, when in reality it has to be done via MMC.  Even know it's pointed out in the guide, people (me) will ignore those instructions and just installed it to the personal user account.

In any event, I was able to get it working and after tweaking the DNS settings a little, now have remote access via certificates utilizing dyndnamic dns to locate the site in the even of ip address changes.

Roveer

Same situation…
I'm going crazy. No traffic passed, tunnels are up.

Status of IKE charon daemon (strongSwan 5.6.0, FreeBSD 11.1-RELEASE-p4, amd64):
  uptime: 34 minutes, since Nov 21 23:31:39 2017
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2
  loaded plugins: charon unbound aes des blowfish rc2 sha2 sha1 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey ipseckey pem openssl fips-prf curve25519 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
Listening IP addresses:
  172.17.0.1
  1.1.1.1
Connections:
        con1:  1.1.1.1...1.1.1.2  IKEv2, dpddelay=10s
        con1:  local:  [1.1.1.1] uses pre-shared key authentication
        con1:  remote: [1.1.1.2] uses pre-shared key authentication
        con1:  child:  172.17.0.0/24|/0 === 172.18.0.5/32|/0 TUNNEL, dpdaction=restart
        con2:  1.1.1.1…1.1.1.3  IKEv2, dpddelay=10s
        con2:  local:  [1.1.1.1] uses pre-shared key authentication
        con2:  remote: [1.1.1.3] uses pre-shared key authentication
        con2:  child:  172.17.0.0/24|/0 === 172.19.0.0/24|/0 TUNNEL, dpdaction=restart
        con3:  1.1.1.1…1.1.1.3  IKEv2, dpddelay=10s
        con3:  local:  [1.1.1.1] uses pre-shared key authentication
        con3:  remote: [1.1.1.4] uses pre-shared key authentication
        con3:  child:  172.17.0.0/24|/0 === 172.20.0.5/32|/0 TUNNEL, dpdaction=restart
Routed Connections:
        con3{31}:  ROUTED, TUNNEL, reqid 12
        con3{31}:  172.17.0.0/24|/0 === 172.20.5/32|/0
        con2{30}:  ROUTED, TUNNEL, reqid 5
        con2{30}:  172.17.0.0/24|/0 === 172.19.0.0/24|/0
        con1{29}:  ROUTED, TUNNEL, reqid 9
        con1{29}:  172.17.0.0/24|/0 === 172.18.0.5/32|/0
Security Associations (2 up, 0 connecting):
        con1[11]: ESTABLISHED 21 minutes ago, 1.1.1.1[hostname]…1.1.1.2[hostname2]
        con1[11]: IKEv2 SPIs: 1efef03e2b08a88d_i* 7a41b86c18992768_r, rekeying disabled
        con1[11]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
        con1{23}:  INSTALLED, TUNNEL, reqid 9, ESP SPIs: c00b6694_i cab18720_o
        con1{23}:  AES_CBC_256/HMAC_SHA1_96, 0 bytes_i (0 pkts, 1264s ago), 0 bytes_o, rekeying disabled
        con1{23}:  172.17.0.0/24|/0 === 172.18.0.5/32|/0
        con2[2]: ESTABLISHED 33 minutes ago, 1.1.1.1[hostname]…1.1.1.3[1.1.1.3]
        con2[2]: IKEv2 SPIs: c7a47c3eb18f920c_i* d2ec51de7a9225b4_r, rekeying disabled
        con2[2]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
        con2{7}:  INSTALLED, TUNNEL, reqid 5, ESP SPIs: c1a231c3_i cd541fd9_o
        con2{7}:  AES_CBC_256/HMAC_SHA1_96, 6384 bytes_i (76 pkts, 87s ago), 16568 bytes_o (109 pkts, 87s ago), rekeying disabled
        con2{7}:  172.17.0.0/24|/0 === 172.19.0.0/24|/0

Quick update on what I have found: I continued to go down the SAD error rabbit hole.  I did find that SADs are not refreshing and it does appear to correlate to my connection troubles.  The pfsense docs show there should only be one SAD entry in each direction per public IP address of each active peer on the tunnel.  My instance had two per.  I did watch the entires go from 1 to 2 and then back to 1.  Network connectivity followed with up then down then back up.  I found a Cisco article that described something similar.  Their suggestion was to increase the timers for the renegotiation.  I have done that and we'll see if connectivity stabilizes.  Still feel like I'm poking around in the dark  :)

Sources:
https://doc.pfsense.org/index.php/IPsec_Status

https://supportforums.cisco.com/t5/other-security-subjects/ipsec-sa-renegotiation/td-p/183064

https://redmine.pfsense.org/issues/4268

Sure, you just need to setup a dynamic DNS hostname on the side that changes. Then on the static side, use that hostname as the peer address.

I got it to work.  Amazing what 3 hours of sleep can do.

Added a P2 on both sides pointing to each other and it came right up.

Solved  , I had a typo on the phase two on one side, for the VLAN subnet…...

If it works unreliably it is not firewall rules.

Hard to say here what needs to be done on the Cisco side to allow pings to its LAN address.

If your pfSense firewall rules on LAN allow traffic to the remote network and the IPsec tunnel is up, that is all that needs to be done.

Rules allowing connections from the remote network go on the IPsec tab.

maybe your lifetimes are a bit messed up or the re
try setting the lifetime of the phase1 to 86400 seconds (=24h). then set the lifetime of the phase2 to 43200seconds (=12h). next time the tunnel goes down, then we can easier figure out if its a phase1 or 2 problem.

to make it automatically reconnect, you can also check if dead peer detection in phase1 is enabled.

if the tunnel is down, can you check if the phase1 or only phase2 is down?

I have the exact same problem. I can't acces my other vlans through the mobile client connection from my laptop. I tried with various firewall rules with no success. Any pfSense vlan masters here? :)

@JJA:

I'll upgrade later because it's a sensitive firewall.

Or you can upgrade it now, because that version is 5 years old and we have fixed thousands of bugs and some critical security issues since then. Nothing is so "sensitive" that it warrants ignoring security updates for 5 years. If it's that mission-critical, it should be running HA and then you can upgrade without downtime.

@JJA:

Is it possible to NAT on IPSEC with PfSense 2.0.2 ?

No. It was a new feature in 2.1.

Thanks for clearing that up! I sent the client a link to this thread which I hope they share with the Cisco person.

Not with IPsec or LDAP. There isn't any way for the firewall to determine which user to associate with a given set of rules.

If you used RADIUS with IPsec, you could allocate each user a static IP address and then use rules/aliases to accomplish the task.

If you used OpenVPN, you could have each set of users connect to a distinct VPN port with different sets of CA/Cert structures depending on the access level – or you could have everyone connect to the same one but allocate static addresses and filter that way.

someone got a hint on this?

network.png
network.png_thumb