I found the problem to be that pfSense requires the WAN (and possibly all interfaces) to have an IP before the racoon service will start. I find that to be slightly odd practice, as the lab I'm trying to create has nothing to do with that interface. Maybe I'm crazy, but spend a few hours trying to troubleshoot an issue that shouldn't exist in the first place.

@rtrinkle:

Thanks for the comment. I read on the pfsense tutorials the limitations of IPsec and overlapping IP address space. It never really dawned on me that the /8 was too broad. I do have resources that would be helpful to be reached on the full /8 segment, however, once I changed the address space to something that didn't overlap all was well. Thanks for your help!

You're welcome :)

@rtrinkle:

In addition, I was under the impression that because the local routes are in the pfsense routing table it would take precedence over VPN traffic. Case in point, all traffic was being shot out of the VPN because of the broad address range. Now I know how the internals of pfsense works, which in turn has helped me understand how it performs traffic routing.

The way IPsec works, it just grabs the data in-kernel before the routing table is even consulted. That's just a side effect of how it works under FreeBSD (and probably other OS implementations). If you were using OpenVPN instead, you can selectively route things a lot cleaner, and the routing table is respected (though you still can't overlap subnets).

the only trick seems to be:
route delete 192.168.250.1 every 5 min by the cron.

Giacomo

@jimp:

On pfSense, try to enable "Prefer old IPsec SAs" under the advanced options. I have to enable this when talking to some other routers (Linksys, Watchguard, etc)

Thanks,  I will try that and see what happens.

-kg

After going back to 1.2.3 it is working fine as well. I did not check the 'prefer old sa' box.

DPD: 60 Sec

Phase 1
Mode: Main
My Identifier: Domain (user@domain)
Encryption: 3DES
Hash: SHA1
DH Group: 5
Lifetime: 28800
Auth: PSK

Phase 2
Protocol: ESP
Encryption: AES128 (others unchecked)
Hash: SHA1 (MD5 unchecked)
PFS: on/DH5
Lifetime: 28800

Perhaps someone else could use this info…

Also I disabled NAT-T on the WG, but this is also handled out so I guess it was not the problem.

OK - got it working now!

In fact, we only need connectivity between networks A and C.

Setting up:

On A:
src A, dst C

On B:
src C, dst A

Seemed counterintuitive because the tunnel was terminating in B, which never gets referenced.  But it worked (after some unrelated but confounding firewall issues were resolved).

Thanks for your patience - I understand IPSEC a little better now.  :)

Unfortunately you cannot NAT an address for IPsec in pfSense. It's a limitation of the underlying software. It's been talked about before, and a bounty was even put up at one time, but no solution has been completed.

As for static routes, you can set routes to external addresses on WAN, but they must be in the same subnet as WAN. You can't set a route to an arbitrary IP, it has to be a directly connected path.

Update, got this fixed, had created a specific NONAT rule for one of the interfaces, removed this, also cleaned up the VPN settings to match the remote system exactly (Key lifetime) and all seems stable now, not really sure which fixed it, but as this was stable beforehand I think it may just be a combination.

J

You may or may not get that to work on 1.2.x, depending on how well the router in front of pfSense handles IPsec passthrough.

2.0 has (or will have? not sure if it's 100% yet) NAT-T which will make the scenario you are describing work regardless.

Enabling old IPSec SA did the trick.

Much appreciated.

Bit odd I hadn't enabled this for the past 3 months and no issues untill recently.

@XIII:

did that fix it?

nothing needed to be changed, it was configured correctly. so in short, no.

I think it may have been just the domain name, have been trying varous settgins back and forth though. Will try to not use only domain name then and see if that does it.

Thanx,

IPSec keeps all of that straight. You could have ten or twenty different tunnels with as many subnets terminating at the same IP address.

You may be used to setting up services that use a single listening port at a remote host, and once that port is connected it can't be used for any other connections. IPSec doesn't work that way, fortunately.

dont use DES if you are concerned about security or unless forced to do so, the keys are small (56 bit) and therefore weak, as a result it is considered insecure
use 3DES or any of the others

Ok, never mind. I did a new install with 2.0 beta from 19 Jan 2010. Everything worked as i expected straight away. No issues routing to either subnet.

@kristaps.kr:

Hello

Need to make three IPsec tunnels, one is working (A), others (B,C) is just silent, no errors in logs, nothing, no activity.

Network looks like this site (A and B have both pfsense 1.2.3 :

SITE A (192.168.3.0/24) –---
   |                                        \      Tunnel B       
   |                                         
   | Tunnel A                               WAN ------------ CISCO (10.0.100.0/24)
   |                                           /
   |                                        /      Tunnel C
SITE B (192.168.4.0/24) -----

Tunnel A works in any conditions, until i disable it.

Tunnel B,C doesn't show any living response, always yellow, and it doesn't try to connect to cisco remote gateway. just silence.
after reboot both (A,B) routers tunnel A is up, B, C is down and not any logs.
tried to switch on/off IPSec the same result. For 24 for hours if B anC tunnels are left on it doesn't try to connect to cisco.
when i delete tunnel A on both sites (A and C) tunnels dissapear from SAD, SPD exists, Overview is empty. logs say nothing.
Tunnel A: aggressive, UserFQDN
Tunnel B,C: main, MyIP

could it be possible that there were upgrade from 1.2.2 to 1.2.3 for both pfsense routers? after this.

one more strange thing which i found from time to time, that ipsec croses subnets wrong ways
should be (for site B LAN 192.168.4.254)
IPsec 192.168.4.0 to 192.168.3.0
IPsec 192.168.4.0 to 10.0.100.0
but in logs several times it was
IPsec 192.168.4.0 to 192.168.4.0
IPsec 192.168.3.0 to 10.0.100.0

i understand that sounds "great" but seems that i am 5 minutes befor reinstall.

thnx

my solution

when i made second tunnel to 10.0.100.0 it doesn't want to came up
in tunnel settings local subnet was "LAN network"
when i changed it to Network and pushed to use the same network with same subnet 192.168.4.0/24
tunnel started to work.
now both tunnels work

hope that this will help to someone

thnx
kristaps