The way IPsec "grabs" the traffic in the kernel, NAT can't be done on it in any traditional way.

It's not in 2.0 now. At one point there was a bounty for it, but it was withdrawn before it was completed. Check the expired bounties forum if you want to read all the details.

Can you please post a picture or diagram of what you are trying to do?  Screenshots of what you have configured in pfSense would be very helpful.

Sorry, my mistake.  Your screen grabs looked just like the site-to-site tunnel config screen.

What kind of logs does your client get during tunnel negotiation?  What kind of client are you using?

Correct. With a PKI setup you need that option ticked so the B can reach C via A.

@jimp:

That still suggests that phase 2 is not matching in some way. Hard to say how, it usually logs something about why, but it may even be a mismatch in the subnet definitions on either end for the internal networks.

Can you post a listing of the ASA config and screenshots of the pfSense side?

You is almost spot on…

I did som debugging on the ASA and discovered a very interesting thing:

The access-list for matching interesting traffic was made by the WEB-GUI and was like this:

access-list OFFICE_nat0_outbound extended permit interface OFFICE-LAN 192.168.2.0 255.255.255.0

Changed this to the ip-address instead, and it worked - just like this:
access-list OFFICE_nat0_outbound extended permit ip 192.168.6.0 255.255.255.0 192.168.2.0 255.255.255.0

According to log address-mask was not matching when using interface-name in access-lists, but mask was the same all over on interfaces (ie. /24)...!

Log from ASA was showing (when I did ICMP ping from pfSense toward ASA):
Static Crypto Map check, map = outside_map, seq = 20, ACL does not match proxy IDs src:192.168.1.0 dst:192.168.6.0

This is RIGHT...! But the ASA dont like it at all...  ;D  So I changed the interface name to the actual address and mask - and then it worked like a charm...!

Thanx for help everyone...

Regards
Knudsen

Hey guys,
  Sorry for the minimalist post.  I'm running version 2.0.  I've read this blog post.

http://blog.pfsense.org/?p=174

I can't seem to find the doc on how to do this anywhere, did this get cut in order to get the 2.0 release out earlier?

Thanks

I've already have this probleme.
i've fixed it by set 3DES encryption algo in phase 2, in pfsense and in shrewsoft.

Benoit

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.