@SpaceBass: Is there a reason you'd want to to use the WAN connect? The effective bandwidth difference shouldn't be noticeable. One way to force it to use the WAN is to block the port (32400) with a firewall rule between the VPN connections. Make sure to open the port for the WAN connection too. Your suggestion worked :-) Many thanks

After upgrading to BlackBerry from 10.3.2 to 10.3.3. my vpn ikev2 connection (as described by TKenny on October 21, 2015, 11:34:40 pm) did not work anymore, although I did not change anything in the vpn setting (on BlackBerry or pfSense). Did get some authentication error, which I couldn't solve. However, because I also had to upgrade my pfSense box from 32-bit to 64-bit in order to get the latest pfSense version, I tried again with my new acquired pfSense hardware box: just worked the first time after setting up pfSense and new vpn connection on BlackBerry. So, just to confirm this set-up still works perfect (with BlackBerry 10.3.3 and pfSense 2.4.2)!

You'll need to use freeradius for user auth and hand out specific IP addresses to each user.. I hand out 172.16.9.0/25 for my own use, allowing me to access the internet + all my local LANS and 172.16.9.128/25  to friends so they can use UK based TV services when abroad, etc … https://forum.pfsense.org/index.php?topic=129443.msg750980#msg750980 A typical user looks like this :- "andy" Cleartext-Password := "XXXXXXXXX", Simultaneous-Use := "1" Framed-IP-Address = 172.16.9.1, Framed-IP-Netmask = 255.255.255.0, Framed-Route = "0.0.0.0/0 172.16.0.1 1" [image: Untitled.png] [image: Untitled.png_thumb]

This was sorted after updating to 2.4.2.

I found the problem: under VPN -> IPsec -> Mobile Clients under 'Client Configuration', the 'Virtual Address Pool' has to be a completely different network address than the internal IP addresses I was using. This tip is on one of the how-to pages, and it looks like I overlooked a step. I also learned that there isn't a way yet to have the DHCP server assign IP addresses to VPN clients.

Its quite easy,  just configure your site to cisco template and then need to change some settings manually

Seems to be solved by disableing DPD on both sites, however don’t understand why….

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.