What does "do not go alone" mean? they don't try to initiate/connect automatically?

They will if you fill in the "automatically connect" IP for each Phase 2. Or just make sure there is always some traffic trying to use the tunnel.

It will come up when it is needed.

Haha you could be right.

So after a lot of changing over the last few days I think i've found a fix.  I had tried setting the "Enable MSS clamping on VPN traffic" a few days ago but it didnt work using the default 1400 value.
I've just changed it to 1370 on both pfsense boxes and its working!!

Can some explain to be why 1370 worked and why 1400 wouldnt?  Is it just a case that a router between the two sites doesn't support a MTU of 1400?

Thanks,
Daniel

I was able to figure my issue out, turns out I had forgotten to create the firewall rules..

rookie mistake heh.

No one any idear?

This may be off base, but wouldn't this be transport mode and not tunnel?  Transport mode encrypts between public IP's, most commonly seen used when a machine floats on the Internet without a firewall but I would think could also connect to the "public" IP(s) of a firewall to simply encrypt information originating from there?  The traffic would flow out of the WAN interface but that's how it should be?

@c3llc:

All-

So I have a client with an interesting issue.   They are using pfSense 2.0.1 to connect to a trading partner.   This partner requires the use of an IPSec encrypted tunnel using PUBLIC IP addresses.

The protected networks happen to be the IP address of the WAN interface on our end and two addresses on their end (essentially a /31 network).

We have the tunnel configured, and it shows as green in pfSense.   They report that the tunnel shows up on their end as well.

The problem is that pings to either of the two IPs on their end are being routed out the WAN interface and not out the IPSec interface!   ???

Is there any way to fix this?

We had this exact configuration working with a Cisco ASA5510, but that box has been retired in favor of the pfSense virtual machine.

HELP!!

Thanks in advance,
Rick

I use it, for the whole year, in a production VPN with 2.0.1-RELEASE devices and Fortinet FortiOS v.4.x devices. All IKE sessions use DH group 14 (the maximum supported by FortiOS standard edition) without any problem.

Many thanks.

@doktornotor:

@greminn:

OK thanks for this! I see.. I gave this a go, but had issues - do i need to change anything at the Fortigate end? Is side one the local end or the remote end?

Changes are requires to be done on both ends of the tunnel, of course.

OK so i changed both ends Phase 2's to only have a single IP address in the remote range… when trying to bring up the VPN i get these errors in the logs:

Aug 8 08:48:36 racoon: [New Media DC VPN]: INFO: IPsec-SA established: ESP 203.167.xxx.x[500]->103.2.xxx.xxx[500] spi=3405420369(0xcafa9751)
Aug 8 08:48:36 racoon: [New Media DC VPN]: INFO: IPsec-SA established: ESP 203.167.xxx.x[500]->103.2.xxx.xxx[500] spi=50113689(0x2fcac99)
Aug 8 08:48:36 racoon: [New Media DC VPN]: INFO: initiate new phase 2 negotiation: 203.167.xxx.x[500]<=>103.2.xxx.xxx[500]
Aug 8 08:48:24 racoon: INFO: unsupported PF_KEY message REGISTER
Aug 8 08:48:24 racoon: INFO: unsupported PF_KEY message REGISTER
Aug 8 08:48:24 racoon: INFO: unsupported PF_KEY message REGISTER
Aug 8 08:48:18 racoon: ERROR: failed to get sainfo.
Aug 8 08:48:16 racoon: ERROR: failed to get sainfo.
Aug 8 08:48:12 racoon: ERROR: failed to get sainfo.
Aug 8 08:47:57 racoon: ERROR: failed to get sainfo.
Aug 8 08:47:35 racoon: ERROR: failed to get sainfo.
Aug 8 08:47:13 racoon: ERROR: failed to get sainfo.
Aug 8 08:47:06 racoon: ERROR: failed to get sainfo.
Aug 8 08:46:58 racoon: ERROR: failed to get sainfo.
Aug 8 08:46:54 racoon: ERROR: failed to get sainfo.
Aug 8 08:46:50 racoon: ERROR: failed to get sainfo.
Aug 8 08:46:50 racoon: INFO: unsupported PF_KEY message REGISTER
Aug 8 08:46:50 racoon: ERROR: no iph2 found: ESP 103.2.xxx.xxx[500]->203.167.xxx.x[500] spi=225044466(0xd69e7f2)
Aug 8 08:46:50 racoon: INFO: unsupported PF_KEY message REGISTER
Aug 8 08:46:28 racoon: ERROR: failed to get sainfo.
Aug 8 08:46:28 racoon: INFO: unsupported PF_KEY message REGISTER
Aug 8 08:46:28 racoon: ERROR: such policy already exists. anyway replace it: 192.168.1.0/24[0] 182.236.xxx.xx/32[0] proto=any dir=out
Aug 8 08:46:28 racoon: ERROR: such policy already exists. anyway replace it: 192.168.1.0/24[0] 182.236.127.0/24[0] proto=any dir=out
Aug 8 08:46:28 racoon: ERROR: such policy already exists. anyway replace it: 182.236.xxx.xx/32[0] 192.168.1.0/24[0] proto=any dir=in
Aug 8 08:46:28 racoon: ERROR: such policy already exists. anyway replace it: 182.236.xxx.x/24[0] 192.168.1.0/24[0] proto=any dir=in
Aug 8 08:46:28 racoon: INFO: unsupported PF_KEY message REGISTER
Aug 8 08:46:27 racoon: ERROR: no iph2 found: ESP 103.2.xxx.xxx[500]->203.167.xxx.x[500] spi=139426204(0x84f799c)
Aug 8 08:46:27 racoon: INFO: unsupported PF_KEY message REGISTER
Aug 8 08:46:24 racoon: INFO: purged IPsec-SA proto_id=ESP spi=3405420368.

@doktornotor:

Without posting the screenshots of your setting, no, not really any ideas. There's also debug mode for racoon for a reason. "It does not work" is not something to work with.

Cool.. here are the VPN settings, and the VLAN, WAN and Floating rules as well. Will sort some debug logs of racoon as well.

Thanks!

Simon

Capture1.JPG
Capture1.JPG_thumb
Capture2.JPG
Capture2.JPG_thumb
Capture3.JPG
Capture3.JPG_thumb
Capture4.JPG
Capture4.JPG_thumb

PfSense 2.0.2 seems to be working great. IPSec seems to be stable over the last couple of days.

There seems to be one issue, which maybe some of you have encountered, Enabling UPNP seems to break ipsec.

@kejianshi:

ohhhhhhhh…   haha.
laughing at myself...

When a client is disconnected and reconnected a few minutes later, it probably wont pass traffic.
Its a weird glitch that I've been assured doesn't exist now...   But ok.

Anyway.  Try this.

Connect to your VPN.  Test it.
Now, disconnect and wait 3 minutes.  Then connect again and test it.

I bet it doesn't work now.

Now, go to status > services and press the "restart services" button to the right of racoon / IPsec.

Bet it works now.

That was a problem on older snapshots, and still is if you didn't follow this page exactly: http://doc.pfsense.org/index.php/Mobile_IPsec_on_2.0
Double check every setting (especially Prefer Old IPsec SA)

I am experiencing the same issue on 2.0.3. It ran fine on 2.0.2 though. It seems to die at the end of the phase 2 lifetime. BTW, nothing has changed other than upgrading to 2.0.3.

Yes - For having many many connections that originate from behind a single firewall to a single distant point, openvpn excels.
It doesn't get confused by multiple layers of NAT and things like that.  Doesn't care what port you run it on.  Doesn't much care how many connections you make on that single port either, although I tend to run as many instances as I have physical cores.

Are you using manual outbound NAT?

Would it be a big deal to paste your phase 1, phase 2, any firewall rules you have set up for LAN, and your manual outbound NAT page.

It would probably go alot faster then.

IIRC that means it is trying to use compression with IPsec which we don't have support for.