What do you have in mind?

Jul 8 14:02:22 racoon: [14.99.207.196] ERROR: exchange Identity Protection not allowed in any applicable rmconf. Jul 8 14:02:25 racoon: [Unknown Gateway/Dynamic]: ERROR: Invalid exchange type 243 from 14.99.207.196[500]. Jul 11 21:04:21 racoon: [189.231.225.24] ERROR: unknown Informational exchange received. Those kinds of errors are generally indicative of a mismatch in phase 1 settings, especially Main Mode/Aggressive Mode. It could be someone probing for any IPsec systems out there, or just port scanning, or who knows. As long as you have lengthy PSKs (or certificates) and other such protections on IPsec, you should be fine.

How?

Thanks for the quick reply. The users we are authenticating with are all in group "admins." Doesn't that provide blanket permissions? We added the specific "VPN IPSec XAuth" permission (seems like a good idea); but we still have a bad auth failure. On a "why not?" whim we changed the client ID string used in Phase 1 to match the username provided for Xauth. That didn't help either. Still failing with bad auth.

Hello guys, please a really need a help, even a RTFM (telling which manual) would be much appreciated. Thanks for your time Alberto

Same thing happened to me.  I originally set up IPSec via static IPs for Peer and Identifier.  Now I've been messing around with Dynamic DNS service and nothing has been changed in Phase One settings which worked fine before so I am wondering is IPSec not passing the Dynamic IP correctly to the remote site for authentication? For now I revert back to static IPs until I figure this out. Just for reference: My Firewall: 2.0-RC3 (i386) built on Fri Jul 15 19:39:23 EDT 2011 Remote Site: WatchGuard XTM510 running 11.4.1 firmware.

Transport is the preferred method and it saves you 20 bytes but since the recommended MTU size is 1400 on both GRE + IPsec (Transport mode) = 1440 and GRE + IPsec (Tunnel mode) = 1420 there is no bigger difference between them. Just don't forget to set MTU on GRE interface or you will lose data // rancor

I have noticed that there are some big gaps in the documentation for the Road Warrior IPSec for v 1.2.3 when using it with v 2.0. Obviously I'm aware that this documentation was done specifically for 1.2 but does anyone have any notes on what you need to do different for version 2.0 to get this to work?

It would be a close call on a WRAP. At the very least you need the same tweak to get around the WRAP's ancient BIOS that was required for 1.2.3: http://doc.pfsense.org/index.php/NanoBSD_on_WRAP

Hi, this is by design^^ u cant route IPSEC. What u have to do is to create multiple phase 2 entrys on Pfsense and sarians. Have a look at this example: Each Sarian has a IPSEC Tunnel to ur central pfsense. Sarian A cant reach Sarian B network because there is no route. pfsense               192.168.5.0                 |           |                 |           |                 |           |          Sarian A      Sarian B      192.168.6.0     192.168.7.0 Solution: IPSEC Tunnel Pfsense <-> sarian A Pfsense: add phase 2 like this: localnet: 192.168.7.0/24 remotenet: 192.168.6.0/24 use same encryption as ur first phase 2 entry. Sarian A: i dont know if sarian can have a second phase 2…but u can try to add a second tunnel with the same shared key...this should work. localnet: 192.168.6.0/24 remotenet: 192.168.7.0/24 IPSEC Tunnel Pfsense <-> sarian B Pfsense: add phase 2 like this: localnet: 192.168.6.0/24 remotenet: 192.168.7.0/24 use same encryption as ur first phase 2 entry. Sarian B: i dont know if sarian can have a second phase 2…but u can try to add a second tunnel with the same shared key...this should work. localnet: 192.168.7.0/24 remotenet: 192.168.6.0/24 At the end create fireweallrules on pfsense to allow traffic between sarian A und B and vice versa...thats it. If u have many sarians to connect each other u need to combine networks to minimize phase 2 entries otherwise there is much to configure. good luck cya