If you're using IKEv2, it's what georgeman noted. If it's IKEv1, that means there is some kind of translation happening between the systems. NAT-T is used where NAT-D sees a source IP or port change between the endpoints.

@charliem: Nevermind, that seems to be included in 2.2 release: https://redmine.pfsense.org/projects/pfsense/repository/revisions/2ae99d06ce01d75a705c5c0e2563da4c24643343 What's included in 2.2? Less noisy IPsec logging? [image: ngbbs4ae379ba4c8c9.jpg]

On the new coming 2.2.1 yeah there is.

@cmb: I was helping someone on IRC last week with an Avaya phone with 2.2. Sounds like a bit different of a circumstance, but the phone was sending malformed traffic. It apparently worked with 2.1.5. It appeared strongswan was doing something differently than racoon which triggered a bug in the phone's IPsec client. He had no means of getting to the phone's management interface so we were stuck. You have a spare phone or two you could contribute to the cause? If you can ship me one, I'll experiment and see what works and what changed in behavior between racoon and strongswan there. PM me if you (or anyone) is willing to give us one and I'll get you an address. I'm in the US, FYI, in case shipment destination and associated cost influences your decision. That…. might've been me actually. Encapsulation and rekey was working on 2.1.5, but unfortunately at this point both have to be disabled for it to work properly with 2.2/strongswan. I have an open support ticket and have done some back and forth with jimp on this(as always, he's extremely helpful). I mentioned a very similar sounding situation but with Avaya + Cisco ASA... tl;dr: cisco expects a nat-d payload type 20, and avaya only does nat-d payload type 15. Same solution - disable encapsulation. It appears to have happened when cisco changed some of their more forgiving backend. Link: http://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/116294-problem-nat-00.html I really feel that this is a problem with Avaya's implementation, and that raccoon was simply more forgiving – still kinda a bummer. I'd like to try and get a phone to you. It's not my decision but I might be able to make it happen. They're ~$230 on amazon. I think you would have to set up an IP Office PBX to really get to the root of this issue; with encapsulation enabled the tunnel connects, but the phone just will not see/register with the PBX. iirc, a developer account with avaya can get the 'server edition' that you could run on a vm at no cost. Thank you for your interest in this, Chris. I really appreciate it. sidenote: read the blog post last night. Instantly bought a ticket for the hype train! Choo-choo!

I subscribe to the issue. It is very important for me

Sorry for such a delay in response. We sidelined this project for a while and I just got back on it today. I did some more troubleshooting and determined that the 10.0.10.0 endpoint was the one with the problem. I figured this out by creating IPSEC tunnels from my office to each of 172.16.88.0 and 10.0.10.0. Both Tunnels established but I was not able to pass trafffic between my office and 10.0.10.0 netowrk in either direction. I look over every setting on that firewall again and it all looked good. The only other thing that I though of was that they have DSL at this location and maybe the "DSL Modem" was blocking some tracffic. I logged into the modem even though it is bridged and saw a lot of this in the log: 2015/02/25 22:14:49 EST WRN | kernel          | logInboundBlocked:IN=br1 OUT=ppp0 PHYSIN=eth0 SRC=70.15.110.34 DST=96.10.24.214 LEN=120 TOS=0x00 PREC=0x00 TTL=63 ID=22826 PROTO=ESP SPI=0xc10fb172 2015/02/25 22:14:44 EST WRN | kernel          | logInboundBlocked:IN=br1 OUT=ppp0 PHYSIN=eth0 SRC=70.15.110.34 DST=96.10.24.214 LEN=120 TOS=0x00 PREC=0x00 TTL=63 ID=1003 PROTO=ESP SPI=0xc10fb172 2015/02/25 22:14:39 EST WRN | kernel          | logInboundBlocked:IN=br1 OUT=ppp0 PHYSIN=eth0 SRC=70.15.110.34 DST=96.10.24.214 LEN=120 TOS=0x00 PREC=0x00 TTL=63 ID=7795 PROTO=ESP SPI=0xc10fb172 2015/02/25 22:14:35 EST WRN | kernel          | logInboundBlocked:IN=br1 OUT=ppp0 PHYSIN=eth0 SRC=70.15.110.34 DST=96.10.24.214 LEN=120 TOS=0x00 PREC=0x00 TTL=63 ID=49042 PROTO=ESP SPI=0xc10fb172 Those IPs are the 2 endpoints to the Tunnels: Unfortunately I am at home and when I try to get into the settings of the modem it asks for the "access code" which is printed on the bottom of the modem. I will have to wait until friday at earliest to get that code to see what is set on this thing that is blocking traffic. (Snow Storm here tonight) I will make sure to follow up in  this thread with what I find out Thanks!

Just restart the box to enable unsecure preshared key with agressive mode. The logs at the end are very clear on that. Sometimes the configuration change is not applied on the daemon which will be fixed on newer versions, for now just restart it.

This is about 2.1.5 or 2.2 since it is not very clear?

@jiunnyik: I'm following thread to know how is OpenVPN will cause Ipsec phase 2 not working. I have this issue as well. I too would be intrigued to find out more.  One of my tunnels consists of pfSense 2.1.5 <-> pfSense 2.2, one of the P2s is a supernetted range of VLANs, some of which are OpenVPNs (at the 2.1.5 end).  This has been stable for 11 days. 2.2 end - 192.168.x.0/24 2.1.5 end - 10.x.0.0/16 + 192.168.x.0/24 The 10.x is actually lots of 10.x.y.0/24. y=250,251,252 are OpenVPN tunnels. IPSEC should not care what subnets or for what purpose or even if they exist locally.

I'm by no means an expert either, so take what I say for what it's worth. I had a similar issue, using EAP-MSCHAPv2. In my case, I had to create the cert a very specific way. As the instructions state, I used my local host name for the common name. Then I had to add the external IP address as an IP type alternative name, and also as a DNS type. I get connected just fine now. Only issue I now is, internal DNS names don't resolve. I can only my network devices by IP. Hope this helps. Good Luck!

Ok Seems like 2 good solutions. Thanks for your help

No idea, no logs, cannot test with dead pfSense versions.

Thanks for the link charlie I had not seen that. Will give some of it a go. :D

I have been trying to figure this one out and found something else strange going on. When the Ipsec tunnels are up, if I try to ping that SQL server's IP from Pfsense and from the same interface it connects to, it then seems to direct the traffic back down the Ipsec tunnel as I see the traffic hitting the firewall on the other end. No Ipsec then it seems to go direct. How can I specific that even with IPsec, local addresses can be found locally? May be relevant, but I have compared route tables and Arp tables between Ipsec connected and not connected and they are the same.

Thank you guys. My problem is solved. After comparing the deference between static IP and DHCP IP, I found the static IP PC was using subnet mask 255.255.0.0 instead of 255.255.255.0. Then problem is gone after I changed it to 255.255.255.0.

Thanks!  Been so busy today I didn't have a chance to write and say that I'd done that, but the tunnel still didn't appear to be working, but then we disabled and re-enabled it on a whim and then it suddenly decided to start working! Sometimes it's finding these solutions that can be maddening and at the same time, have you cheering out loud in your cube.

Just to update folks on the forum. We have been following this issue for a while and it appears the Devs were finally able to replicate this. Looks like a fix is being tragetted for 2.2.1. You can follow the link below to monitor progress. https://redmine.pfsense.org/issues/4341

@nikolaii: Hello, just one word: brilliant! I followed your instructions and everything worked flawlessly :) Thank you. Nicolas Cool! Glad to hear it worked for you! :-)