@jvangent100: Would there be a nicer way ? Set [Interfaces: LAN] MTU 1492 too.

@cmb: This is the expected end result given we don't add exclusions for the LAN IP anymore. That'll return in some manner in the future, likely automatically as previous versions did it for 2.2.2. So does this mean I cannot have a remote gateway over IPsec anymore until the exclusions are added again? (for example as explained in https://doc.pfsense.org/index.php/Routing_internet_traffic_through_a_site-to-site_IPsec_tunnel) Hmm, that kind of sucks… Using the instructions described in the link above cause the local LAN to 'disappear' in a way that even clients cannot reach it anymore (and thus cannot access the internet via the IPsec tunnel). Anyone knows a workaround for this?

cmb, thank you for information. Yes, I'm using IKEv2, for security. I didn't know that switching to IKEv2 also [accidentally] activates MOBIKE.  It doesn't seem to have been mentioned in the 2.2 release notes. From pftop status display (below), I can confirm that ESP tunnels between pfSense firewalls with public IP addresses remain pure ESP, not UDP-tunneled. It's just the IPsec status page that displays misleading information. Thanks again! pfTop: Up State 1-100/17675, View: default, Order: dest. port PR    D SRC                  DEST                STATE  AGE  EXP  PKTS BYTES esp  I xxx.xxx.11.62:0      xxx.xxx.84.122:0      2:2  38661    59 8936K 8989M esp  O xxx.xxx.84.122:0      xxx.xxx.227.40:0      2:2  41009    60  228K  40M ... tcp  I 74.125.82.172:33980  192.168.0.75:25      10:10  106    11  491  340K tcp  O 74.125.82.172:33980  192.168.0.75:25      10:10  106    11  491  340K tcp  I 192.168.19.4:4261    192.168.12.20:42      4:4  39727 86274  194 20994 tcp  I 192.168.16.3:1087    192.168.12.20:42      4:4  37625 84775  186 19694 udp  I 192.168.12.26:56079  8.8.8.8:53            1:2    15    15    2  352 udp  I 192.168.12.26:55595  8.8.8.8:53            1:2    12    18    2  276 udp  I 192.168.12.16:56447  23.5.165.172:53      1:2      7    23    2  152 ...

It's also worth mentioning that when I reboot my router, ipsec shows connected, but I am unable to use reach any of the remote subnets. Only after manually stopping then starting the connection through the web ui am I able to use the tunnel. I read in the forums that it may be related to having multiple phase 2 entries, but I am unsure as to how I can reach multiple subnets without multiple phase 2 entries. Any suggestions would be appreciated.

hm, i cause my problem with x509 authenticated IPsec i tried an site-to-site tunnel between PFsense 2.2 and Cisco IOS with PSK and fix IP on both side. There i have the similar problem. This site-to-site only get established, when a client behind PFsense initiates the tunnel to the cisco. When the tunnel is established also the router is able to transfer traffic over the tunnel, but not before. I assumed: the Cisco IOS has about 5 different Phase1 policies, the PFsense has only one. But i don't know how to define only one Phase1 policy for a specific client, also Cisco-Support told me that's not possible, I am unsure if should trust cisco in this statement (had already fights with the cisco support, what is possible and what isn't) best regards Thomas

Hi i am currently fighting with a similar problem. I have an IPsec site-to-site tunnel with x509 authentication. client(192.168.1xx.45) –> pfsense 2.2 (192.168.1xx.4) --> Internetrouter(192.168.1xx.1) --> Internet --> cisco886 IOS (217.zzz.zzz.105) --> Server 192.168.2yy.5 When i try to ping from client 192.168.1xx.45 the server at 192.168.2yy.5 the tunnel gets established on both sides. but i can't transfer any data. also the encryptioncounters on the cisco ios stays at 0. I had the same issue with PFsense 2.1.5 so i assume a bug at the cisco IOS router here. best regards thomas

Bump.  Is this just a limit of the config?

@benw01: @jimp: Did you add the special TCP-specific rules with the extra settings (Any flags, sloppy state) mentioned in the guide? I hadn't done this! Once I added a TCP rule for L2TP Out with the Any flags and sloppy state it's working. Now I just need to get it so that I can connect with Windows and OSX. If I set the DH Key group to 2 (1024), OSX can connect & works fine, but Windows 7 doesn't connect (Error 788). if I set it to DH group 14 (2048), Windows 7 works fine but OSX won't connect. Yay VPNs. This is my post for this problem. https://forum.pfsense.org/index.php?topic=83321.msg496600#msg496600 You can set it to 3DES/SHA1/DH group 2, it'll work for both Mac/Win.

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. [image: ipconfig.png] [image: 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? [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