I was able to configure pfSense as strictly a L2TP/IPSec server but Im not sure how to integrate it into my network correctly.

Most often because you have no firewall rules on the IPsec tab on pfSense allowing the traffic to come in. If not that, you may have firewall rules on the Sonicwall not allowing traffic to leave its LAN destined for the VPN.

Squid almost certainly wouldn't be related. Unless maybe it's shutting down because of a hardware problem that's also affecting strongswan but I would guess that's not very likely as it'd probably crash and reboot the system.

The status described is just how things would look when it's trying to connect and isn't yet connected, it's not that your P1/P2 config isn't there, it's just not existent in status at that point.

No telling what might be happening. IPsec logs would be useful.

Followup incase someone ever has similar problems… Two things...

1. I was unclear about the interface. I said "LAN" but it was a WLAN interface and I think this had something to do with generating the behaviors I was seeing.
2. I "fixed" it by setting the DHCP range on that interface to a range that looked like x.x.x.129-254 and setting the network in the IPsec SAs to x.x.x.128/25 thus pulling the .1 interface (firewall) out of the networks on the tunnel. This worked. Clients in the DHCP range go over the tunnel for internet access and the firewall interface still works as expected.

Hack but it works for now and I'm not going to need more DHCP space there for a while (famous last words...)

Rekeying should not result in any drop in connectivity, as it should complete before expiration and then replace. Leave a constant ping running for around 48 hours and verify you don't have any excessive loss (sub-0.5% assuming a reliable Internet connection). If that checks out, you're fine.

Hey there enrico.m.crisostomo (or anyone else that knows the answer) -

I am experiencing what is mentioned in the OP. I have a working Mobile IPSec VPN, and all mobile devices can see resources on the local LAN subnets. These mobile devices cannot traverse the site-to-site VPN to my servers in the cloud. As stated below, with a traditional site-to-site VPN you would simply add another Phase2 and make sure that the remote side has a route to your new subnet. That idea does not appear to work with a Mobile IPSec VPN.

Does anyone know the resolution to this?

Thanks.

@cmb:

That's still an open issue. https://redmine.pfsense.org/issues/4537

The workaround is to go to System>Advanced, System Tunables, and add a tunable for net.inet.ipsec.directdispatch with value 0.

it works !! thanks :)

No, rules are automatically added. You can check states under Diag>States to confirm whether the traffic is being passed. Filter on the public IP the client is coming from. Can double check nothing is blocked by checking firewall log.

Was able to fix it:
Somehow Key Exchange version been changed to Auto, I changed it to ver 1 which i believe that it was, I then was able to change the Negotiation mode to aggressive.

Thanks for the response!

Yes, i know i can use gateway group for local side. I meant remote side, sorry for being unclear.

That's just the source IP of the traffic it's initiating, has no relation to the identifiers. It will never show anything other than the actual IP assigned to the system in that particular log, it can't just source traffic from an IP that it's being NATed to elsewhere.

The problem is somewhere else, beyond that in the IPsec logs what do you see?

I can understand your frustration but the curt comments you have received are correct.  Phase 2s don't work like that - IPSEC is not routing and it's certainly not a "cloud" that you simply bung packets into and hope that they know where to go.  Also ANY packets that do not match both parts of the P2 will not go over the tunnel.  This is especially important to remember if you try to daisy-chain sites together. eg, three sites:

A – B -- C

To fully connect these you could do this with this number of P2s and the parenthesized (bracketed) number of P1s:

A: AB, AB(C)                (1 x P1)
B: BA, BC, B(C)A          (3 x P1)
C: CB, CB(A)                (1 x P1)

I think I got that right and that's a very simple star with 3 sites only.  Add a site D, only connected to C and the permutations become horrendous.  With a mesh instead, where each site is connected to all the others and adding D (each pair is 1 P1 and a P2):

A: AB, AC, AD
B: BA, BC, BD
C: CA, CB, CD
D: DA, DB, DC

ie (n-1)^2 Phase 1.  With the daisy-chain there is a different relation which someone could perhaps chime in with and for the simple case we could work out the fewest number of P1s and 2s required.  At the start of that discussion we'll be assuming a spherical tunnel 8)

.... or not.  Daisy chaining beyond two hops is really silly and even two hops should only be used if needed to get around a proprietary (Safe@Office anyone?) or technical limitation to the number of P1s available on a device.  It depends on more links working and is horrible to work out.

This far I have deliberately shown the worst case, although I haven't even started on multiple subnets at each site.  Simply multiply the P2 numbers above by the number of subnets at both sites involved - yes that's effectively squaring them.  eg 2 subnets at A and B = 4 x P2s and 2 P1s in total.  Hmmm 8 sites and say 4 VLANs each is going to take some time unless there are some shortcuts.  Nominally we have:

(8-1)^2 = 7 * 7 = 49 P1s
4^2 = 16 P2s per P1 => 49 * 16 = 748 P2s

Now we get to the reasons why you might want to think about your network design before you start cranking out IPSEC on such a setup.

There are at least two strategies that can help reduce the sheer number of P1s and P2s:

1. Do all sites need to reach all other sites?
If you have an HQ site + satellites where all the sat sites only need to get to HQ then probably no. This reduces the number of P1s to

2(n-1) = 2 * (8 - 1) = 14 (down from 49) in this example.

However, if you have an AD DC at each site, you must fixup AD S&S so that the DCs can all sync properly.  The KCC is shit at working out things for itself.  See MS's docs for site bridging and all that bollocks.  If you are using eDir (unlikely, sadly) or OpenLDAP it's easier to deal with.  Other systems may need to be dealt with in various ways.

2. Can we combine all the subnets at a site into one for the purposes of IPSEC?
Careful choice of subnets at each site can reduce the number of P2s from n*m (n is the number at one site and m is the number at another) to 2 P2s per P1 - this can really scale!  For example:

Site A has 20 VLANs: 10.1.{1,2,3 ... 20}.0/24
Site B has 50 VLANs: 10.2.{1,2,3 ... 50}.0/24

With IPSEC we setup the P1 in the usual way to join site A and B but for P2 we can refer to Site A's subnets as 10.1.0.0/16 and Site B's as 10.2.0.0/16 for 1 P2 at each end, or 2 P2s in total.  As an added bonus we can add another (253 minus the number of subnets in use) subnets at each site and it will still work.

Results for 8 sites, each with 4 subnets:

Random set up => (n-1)^2 P1 and (n-1)^2 * sum(n * m) P2
My notation for the P2s is not rigorous and is missing some subscripts and stuff.

49 P1s and and an eyewatering 748 P2s

Simplified networking and collapsable subnets => 2(n-1) P1 and 2(n-1) P2

14 P1s and 14 P2s - Lovely

OK, so we don't have your network layout so can't really design it for you.  However if it was me, I'd probably start a process of network renumbering, given that you seem to be seeking a magic bullet of VPNs - this isn't one.  It should not be a really big deal.  You should be making good use of DHCP where applicable and DNS as well to remove many obstacles to doing this sort of thing.  However I have had to fix far too many bloody networks that were .... *&^^%$£ ...... whatever.

You should now have more than enough information to decide what to do.

Cheers
Jon

@andra.pocherebox:

Well… Being stubborn led me solved by myself!  :D :D

To whole it may interest I found out that to redirect all traffic through VPN, you gotta set up two different Phase2 according to the picture below.

Then both your LAN traffic and Internet traffic will be routed correctly through the VPN endpoint.
Hope this can help!

Cheers

Here's another Kudo coming from a long-time pfSense user.  I also got bit by going from 2.0.1 to 2.2.2.  IPsec "worked", but the route-all-traffic-for-free feature went dead and for all my Google searches I couldn't figure out how to fix it.  I'm primarily using IPsec from IOS and OSX devices, and was wondering why the hell DNS resolution of internal hosts wasn't working.  It wasn't until I deep-drilled some more that I figured out it was a default gateway problem, which finally led me to this post (which I found only by manually browsing the forums!).

So thank you, thank you, thank you!

pfSense mods: this information needs to be part of the IPsec troubleshooting page!  This is obviously a stumbling block for anyone unknowingly crossing the racoon->strongSwan transition, and I got a lot of Google hits asking how to fix this, but precious few answers.

I have moved from PSK to certificates so I can't easily do screen shots for PSK. However if you post shots of your current config, I will be happy to try and help you. Alternatively, I can provide XML fragments for PSK if you are comfortable with that approach.

I'm currently traveling, so it may be a day or two before I can respond.

@dstroot:

dennypage: I have tried unsuccessfully to replicate your setup.  Any possibility of screen shots?  I just can't seem to get it to work.

Hi jimp. Thanks for the response.

Tried that a few days ago and it doesn't work either :/ I have checked the freebsd trunk out and can see that the last changes to the source code for IPsec and ESP is from 2000/2001 and the RFC that describes TFC is from 2005.

So i guess some development in freebsd is needed to make this work.

Outbound NAT is the way to accomplish that.

Well… I've been trying to find a way for this configuration:

1 ipsec server 1 openvpn client

Only solution I see is to use openvpn only, right?

That seems really excessive. Could you PM me the output of "ipsec statusall"?

2.2.3 coming in the not too distant future, a month or less maybe. But not sure it'll solve whatever you're seeing without knowing more about it.