The GUI certs already have that EKU set but Windows also wants another one "1.3.6.1.5.5.8.2.2"

We put some fixes into 2.2.4 to add that into the server cert, so if you update to a snapshot and make a new IPsec server cert it'll be there.

So make sure of the following when making a cert:

Be on 2.2.4 snapshot, -RELEASE or later Cert is selected as a SERVER certificate Common Name must be set to either the IP address -or- FQDN in DNS of the server, whatever the clients will use to connect, can't make both work.

Your CIDR notations for local subnets have some typos in them.  I think the gist is you want 4 local subnets to access a network 10.41.38.0/22 on the remote end since you were going for multiple phase 2.

Did you ever consider GRE over IPsec?  It more or less makes this a routing problem than a multiple SA problem and gives you the ability to adjust MTU per GRE interface/tunnel versus for all IPsec traffic.

I found a YouTube video that helped with the basis for my own configuration with pfSense and an HP router a while back maybe it'll help you too.  HP called the GRE interfaces tunnel interfaces, I think Cisco does as well:

Youtube Video

You'll be on your own for the corresponding Cisco config commands if you go this route.

The only thing of note if you go this route is whenever you reboot pfSense, the GRE interfaces don't like to come up all the way.  You either have to disable/enable them from the web GUI or SSH to pfSense and issue the 'up' command to the interface.  Any workarounds posted on the forums that I've found to use boot time commands from add-on packages didn't work for me.

who can help on that?

Hi guys!

Right, got it!

Thanks in advance!!!

I have another topic about split tunnel. If you guys could help me on that, I appreciate.

Diego

We've actually tried it both ways and are getting the same result.  Using Intel Server adapters on the hardware version, e1000 virtualized adapters on the VM (KVM). They Vyatta is virtuallized, but Rackspace and other people use them all the time for similar configurations without a problem.

Hello pinoyboy,

two things from me on top to this things.

I am a really great fan of pfSense (ok I am a newbie) and also a little bit conservative;

IPSec VPN is common and is also threated in the business world as not broken Terminating the VPN endpoint at the WAN interface of the firewall or UTM (pfSense)

But if there are more problems came with and the business must go on, you can try two things out.

If you are switching to OpenVPN you can try install on both sites (Site-to-Site VPN) a compression card
likes the Comtech AHA363PCIe this would be speeding up the entire throughput. The other way if you must handle more then one VPN method you can fairly try out SoftEther VPN
it accepts nearly all VPN types! We installed a Linux VPN Server in the DMZ and there fore our pfSense
is now running more stable and the linux based server is accepting this cards also!!! Here is a link for it:
SoftEtherVPN And the best, if you want to stay with FreeBSD it is
also available for FreeBSD 10.1, Linux, Solaris, Windows, MacOS.

All common VPN methods are accepted (OpenVPN, IPsec, L2TP, MS-SSTP, L2TPv3 and EtherIP)
So if you have a old server hardware laying around try it out, it used also AES-NI!

The comtech cards are at $30 at eBay and are delivering 5 GBit/s.

I didn't include Phase1/2 timeouts previously.  Phase 1 is 86400 seconds, Phase 2 is 3600 seconds.  Let me know if there is any other info I need to dump out to post.  I'll keep my own speculation to a minimum and report findings.

It seems like another Phase 2 SA is added every 2-3 days.  I put together another output from 'ipsec statusall' similar to the previous post, 2 days afterwards.  The tunnel was not reset on either side in this time frame and another Phase 2 SA was added. (3 total)  The last Phase 2 SA with lines starting with "con2{932}" is the active SA and is the only SA on the other end of the tunnel.

I can wait another few days and post more output to see if the last Phase 2 SA is the active one and we have more than 3 Phase 2 SAs.

Status of IKE charon daemon (strongSwan 5.3.2, FreeBSD 10.1-RELEASE-p13, amd64):   uptime: 10 days, since Jul 07 06:29:17 2015   worker threads: 10 of 16 idle, 6/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 smp 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:   WAN_IP   LAN_IP   GRE0_IP   GRE1_IP Connections:   bypasslan:  %any...%any  IKEv1/2   bypasslan:  local:  uses public key authentication   bypasslan:  remote: uses public key authentication   bypasslan:  child:  LAN_IP/32|/0 === LAN_SUBNET/24|/0 PASS         con2:  WAN_IP...REMOTE_WAN_IP  IKEv2, dpddelay=10s         con2:  local:  [WAN_IP] uses pre-shared key authentication         con2:  remote: [REMOTE_WAN_IP] uses pre-shared key authentication         con2:  child:  WAN_IP/32|/0 === REMOTE_WAN_IP/32|/0 TRANSPORT, dpdaction=restart Shunted Connections:   bypasslan:  LAN_IP/32|/0 === LAN_SUBNET/24|/0 PASS Routed Connections:         con2{918}:  ROUTED, TRANSPORT, reqid 3         con2{918}:  WAN_IP/32|/0 === REMOTE_WAN_IP/32|/0 Security Associations (1 up, 0 connecting):         con2[264]: ESTABLISHED 16 hours ago, WAN_IP[WAN_IP]...REMOTE_WAN_IP[REMOTE_WAN_IP]         con2[264]: IKEv2 SPIs: 18e88abe7009344e_i* 59878b639d3fc838_r, pre-shared key reauthentication in 7 hours         con2[264]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024         con2{930}:  INSTALLED, TUNNEL, reqid 3, ESP SPIs: cf75d264_i 0f545298_o         con2{930}:  AES_CBC_256/HMAC_SHA1_96, 6688 bytes_i (54 pkts, 10s ago), 0 bytes_o, rekeying in 20 minutes         con2{930}:  WAN_IP/32|/0 === REMOTE_WAN_IP/32|/0         con2{931}:  INSTALLED, TUNNEL, reqid 3, ESP SPIs: ce9b2f7f_i 09b24fbe_o         con2{931}:  AES_CBC_256/HMAC_SHA1_96, 22796 bytes_i (184 pkts, 10s ago), 0 bytes_o, rekeying in 21 minutes         con2{931}:  WAN_IP/32|/0 === REMOTE_WAN_IP/32|/0         con2{932}:  INSTALLED, TUNNEL, reqid 3, ESP SPIs: cf4df9d9_i 0567be16_o         con2{932}:  AES_CBC_256/HMAC_SHA1_96, 141348 bytes_i (1141 pkts, 1s ago), 189168 bytes_o (1126 pkts, 1s ago), rekeying in 27 minutes         con2{932}:  WAN_IP/32|/0 === REMOTE_WAN_IP/32|/0

That's likely the mobile ipsec.secrets issue that affected iOS there as well. Upgrade to 2.2.4 and that'll work. Snapshots are stable. Or you can just replace /etc/inc/vpn.inc with the latest, then click Save under Status>IPsec to apply.

In addition to answers to the previous post, also try running```
ping_hosts.sh

I did, two days ago. It turns out the problem wasn't my end at all. The guy in charge of the router on the other end transposed some number or something (he was kind of vague about it) so my connection wasn't authorized to access anything on his network. I'm pretty sure he just typed in my external IP wrong.

He fixed that on his end, and voila, a perfect connection. The client is very happy.

Thanks for the help, and for the reminder to update the thread!

@mattboston:

Also, the BINAT will map

172.16.23.1 to 10.10.23.1
172.16.23.2 to 10.10.23.2
…
172.16.23.254 to 10.10.23.254

correct?

Yes, that is correct.

Thanks, that solved my problems. As a newbie on pfSense, I thought the guides painted a fairly pain-free picture of setting up IPsec, and my tunnels connected just fine, but absolutely no traffic passed through… Was pulling my hair out before I found this answer, and everything works brilliantly now, so - THANK YOU!

Cheers,
Örjan

Ok cmb, I was finally able to reproduce the problem on my 2.2.3 test environment. Tried latest 2.2.4 snapshot (20150715-1754).

I confirm it does solve my problem. I see that it uses %any as left identifier on ipsec.secrets. All tunnels up with it.

Some notes on reproducing the problem:

Past Monday I reworked my test env to look a little bit more with the real case. I've setup 2 pfSense 2.2.2 vms A and B with 2 WAN links each. All wan networks are different and are routed among each router by a third pfSense vm P. I had 2 ipsec tunnels on each, between WAN1A-WAN1A and WAN2B-WAN2B. One of the tunnels used a distinguished name identifier on side B. With all that working, I updated B to 2.2.3. But still worked fine.

Today I added a third tunnel to B, against a cisco router (same as my real case). Then the problem showed up. It seems dependent on the interface I attach the tunnel to. One works, the other one doesn't. It's the same thing as described on my original post, and the workaround of changing the ipsec.secrets file manually also worked.