If the connection required NAT-T, it just plain wouldn't work. NAT-T isn't compiled in at all, it'll be refused if proposed or attempted, there is nothing "partial" about the support (see snippet posted by Vorkbaard above).

Even with that device behind NAT you probably don't actually need NAT-T, though that depends on what kind of NAT device it's behind, and possibly a number of other things on their end.

If it negotiates, but doesn't re-negotiate, it's not related to NAT-T. It could be related to many other things. Logs from both ends may help. In these kinds of scenarios with any devices where there are difficulties with two different vendors (regardless of vendor) you may need to crank up the log levels on both ends, which on the pfSense end means running racoon in debug mode.

This shouldn't be a problem. Read the guides or buy the pfSense book.

In a Multi-WAN setup, you would need to use only one WAN for the tunnels. This info is listed in the docs also.

http://doc.pfsense.org/index.php/Category:Howto

It looks like a mismatched phase 2 key. The error logging does not always provide definitive answers though. If you provide your config, you will more likely get a better response.

Hi, just had to register to say thanks.

I have been using. pfsense 1.2.3 on watchguard x1000 hardware and been trying to tunnel with both m0n0wall and sonicwall.
the tunnel has always come up no problem but the damn traffic didn't go through!

but changing to md5 instead of sha1 made the difference! crazy really and i have been thinking about changing from pfsense just because of this.

so thank you.

I had this problem a few times after upgrades:

http://forum.pfsense.org/index.php/topic,15878.msg94828.html#msg94828

during the last upgrade to 1.2.3 Release, it was fine, no problem.

If i remember, all i needed to do was go into my configuration and save it again.

There are no software limits. There are some pfSense installations out there that have 200-300+ tunnels going at once.

Like a charm, thank you!

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