i have the same problem …
if the pfsense open the vpn tunnel it works ... but if the fritzbox 7490 open the connection the tunnel dont works ...

the same config with older fritzbox works very good

@hege:

Which DNS server you have set in the mobile clients section?

Open a CMD and type nslookup, what is the Output with / without the VPN connection?

Thank you for responding.

Well, the doc I followed (linked in my original post) does not mention entering a DNS server. So I didn't enter one at first. Since when I wasn't able to reach the hosts inside my lan, I did try entering the IP of my PF box. Still not luck.

To test from 'outside' my network, I am using internet sharing on my phone. when connected through my Phone nslookup returns my phone and it's IP as the default server and address. I get the same result whether I have the VPN connected or not.

Going one step further, ipconfig /all still shows no entry for DNS server on the VPN interface.

ipconfig.png
ipconfig.png_thumb

I figured it out.. My floating rules were mis-matched for the L2TP interface.

it works.

thank you ermal!

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?

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.