Hi, this is just what I was looking for, and it works like a charm. THANK YOU!

Now for a follow-up question: I have a webserver in site B that used to be available on its (public, external) ip address thanks to nat reflection. Now that outbound nat rule generation is no longer done automatically, that server is no longer available from within sites A and B. From outsite it still works fine.

We have 6 public ips in a row and this webserver is not on PfSense's public ip address but on one of the others.

I take it I must tell PfSense somewhere that that server must be reachable from inside the lans, but where and how?

/edit
Ok I found the solution: under Firewall > NAT > Port Forward, for every port forward rule I had to set NAT reflection to Enable (Pure NAT). Also under System > Advanced I ticked Enable NAT Reflection for 1:1 NAT and Enable automatic NAT for Reflection. I think using all three options might be redundant but it works.

I see it here all the time:

I'd only get worried if my user password was user1/password1 or some other simple thing and my shared secret was "shared".
As long as its saying "exchange Identity Protection not allowed in any applicable rmconf" I'm not worried.
I'll get worried when its not throwing that error :o
(It would be nice to get some fail2ban like functionality in pfsense for IPsec, SSH, Openvpn and all the other places guys like my little friend from Amsterdam here will try to get into.)

Jul 23 03:28:45 racoon: [193.67.0.27] ERROR: exchange Identity Protection not allowed in any applicable rmconf.
Jul 23 03:28:45 racoon: ERROR: Invalid exchange type 243 from 193.67.0.27[26129].
Jul 23 03:28:49 racoon: [193.67.0.27] ERROR: exchange Identity Protection not allowed in any applicable rmconf.
Jul 23 03:28:49 racoon: ERROR: Invalid exchange type 243 from 193.67.0.27[26129].
Jul 23 03:28:50 racoon: [193.67.0.27] ERROR: exchange Identity Protection not allowed in any applicable rmconf.
Jul 23 03:28:50 racoon: ERROR: Invalid exchange type 243 from 193.67.0.27[26129].
Jul 23 03:28:51 racoon: [193.67.0.27] ERROR: exchange Identity Protection not allowed in any applicable rmconf.
Jul 23 03:28:51 racoon: ERROR: Invalid exchange type 243 from 193.67.0.27[26129].
Jul 23 03:28:54 racoon: [193.67.0.27] ERROR: exchange Identity Protection not allowed in any applicable rmconf.
Jul 23 03:28:54 racoon: ERROR: Invalid exchange type 243 from 193.67.0.27[26129].
Jul 23 03:28:57 racoon: ERROR: Invalid exchange type 243 from 193.67.0.27[26129].
Jul 23 03:28:57 racoon: [193.67.0.27] ERROR: exchange Identity Protection not allowed in any applicable rmconf.
Jul 23 03:28:58 racoon: [193.67.0.27] ERROR: exchange Identity Protection not allowed in any applicable rmconf.
Jul 23 03:28:58 racoon: ERROR: Invalid exchange type 243 from 193.67.0.27[26129].
Jul 23 03:28:59 racoon: [193.67.0.27] ERROR: exchange Identity Protection not allowed in any applicable rmconf.
Jul 23 03:28:59 racoon: ERROR: Invalid exchange type 243 from 193.67.0.27[26129].
Jul 23 03:29:02 racoon: [193.67.0.27] ERROR: exchange Identity Protection not allowed in any applicable rmconf.
Jul 23 03:29:02 racoon: ERROR: Invalid exchange type 243 from 193.67.0.27[26129].
Jul 23 03:29:05 racoon: [193.67.0.27] ERROR: exchange Identity Protection not allowed in any applicable rmconf.
Jul 23 03:29:05 racoon: ERROR: Invalid exchange type 243 from 193.67.0.27[26129].
Jul 23 03:29:08 racoon: [193.67.0.27] ERROR: exchange Identity Protection not allowed in any applicable rmconf.
Jul 23 03:29:08 racoon: ERROR: Invalid exchange type 243 from 193.67.0.27[26129].
Jul 23 03:29:11 racoon: [193.67.0.27] ERROR: exchange Identity Protection not allowed in any applicable rmconf.
Jul 23 03:29:11 racoon: ERROR: Invalid exchange type 243 from 193.67.0.27[26129].
Jul 23 03:29:14 racoon: ERROR: Invalid exchange type 243 from 193.67.0.27[26129].
Jul 23 03:29:14 racoon: [193.67.0.27] ERROR: exchange Identity Protection not allowed in any applicable rmconf.
Jul 23 03:29:17 racoon: ERROR: Invalid exchange type 243 from 193.67.0.27[26129].
Jul 23 03:29:17 racoon: [193.67.0.27] ERROR: exchange Identity Protection not allowed in any applicable rmconf.
Jul 23 03:29:20 racoon: ERROR: Invalid exchange type 243 from 193.67.0.27[26129].
Jul 23 03:29:20 racoon: [193.67.0.27] ERROR: exchange Identity Protection not allowed in any applicable rmconf.
Jul 23 03:29:23 racoon: ERROR: Invalid exchange type 243 from 193.67.0.27[26129].
Jul 23 03:29:23 racoon: [193.67.0.27] ERROR: exchange Identity Protection not allowed in any applicable rmconf.
Jul 23 03:29:26 racoon: ERROR: Invalid exchange type 243 from 193.67.0.27[26129].
Jul 23 03:29:26 racoon: [193.67.0.27] ERROR: exchange Identity Protection not allowed in any applicable rmconf.
Jul 23 03:29:29 racoon: ERROR: Invalid exchange type 243 from 193.67.0.27[26129].
Jul 23 03:29:29 racoon: [193.67.0.27] ERROR: exchange Identity Protection not allowed in any applicable rmconf.
Jul 23 03:29:32 racoon: ERROR: Invalid exchange type 243 from 193.67.0.27[26129].
Jul 23 03:29:32 racoon: [193.67.0.27] ERROR: exchange Identity Protection not allowed in any applicable rmconf.
Jul 23 03:29:35 racoon: ERROR: Invalid exchange type 243 from 193.67.0.27[26129].
Jul 23 03:29:35 racoon: [193.67.0.27] ERROR: exchange Identity Protection not allowed in any applicable rmconf.
Jul 23 03:29:38 racoon: ERROR: Invalid exchange type 243 from 193.67.0.27[26129].
Jul 23 03:29:38 racoon: [193.67.0.27] ERROR: exchange Identity Protection not allowed in any applicable rmconf.
Jul 23 03:29:41 racoon: ERROR: Invalid exchange type 243 from 193.67.0.27[26129].
Jul 23 03:29:41 racoon: [193.67.0.27] ERROR: exchange Identity Protection not allowed in any applicable rmconf.

I've had all kind of issues with 2.0.x and even 2.1 with regards to IPSEC.  This is the reason I've stayed 1.2.3 for most sites; rock solid with required IPSEC connections.  Also, having to work with other VPN devices, IPSEC is standard use.  Try it and see if it helps you.

Hello,  The lancom not allowing multiple phase 2 entries will probably be a problem for you.  I believe there needs to be a pair of SA entries PER subnet.  So the lancom would also need to know about your mobile network.

Of course, you MIGHT be able to use a larger cidr network…

change the ipsec tunnel between the lancom and your pfsense box to be 192.168.16.0/23.  <-- note the 23 change your mobile network from 172.16.17.0/24 to 192.168.16.0/24

The 192.168.16.0/23 network is shorthand for
192.168.16.0-192.168.17.255.

--jason

Hello,

The first thing to remember is that the firewall is a default "block all", therefore you only need to allow access from their hosts to your one.

(Rule is set up as BLOCK)
x  IPv4 * 172.16.5.0/24 * ! 192.168.111.4 * * none   Only allow remote network to access single local host
…
Block any packet from the supplier network (by definition over the IPsec VPN) that isn't destined for the desired single host on my network

Second is to remember that rules apply on INBOUND connections, thus you want a rule like this on your IPSEC interface.

Thus, the psuedo-code would read:

"allow all traffic from 172.16.5.0/24 to 192.168.111.4"

–jason

Correct, NAT+IPsec will only work on 2.1 using the NAT option in the Phase 2 settings.

Hmmmm.
Which version of windows are you using?

If its not windows XP, you need to right click the install file and "run as admin" otherwise you get connected but won't route you anywhere.
If you didn't install it as admin, easy fix is uninstall it, then reinstall (Run as admin this time).

Occasionally you get an issue where you have to allow it in your firewall rules on a windows box, depending on the firewall.

@Pinuccio:

It took me a while but after finding out that the reason must be on the pfsense router I started to cut off some services and finaly found out that it was the traffic shaper.
It was misconfigured for the other services.

I thought this Information can be usefull to anyone.

Ah yeah, I conconfigured the damned thing so that by using kbits instead of mbits… Needless to say, I needed serial console to rescue.  :-[ ::)

IT is definitely a pfsense issue.
The Checkpoint side sends subnets, but my pfsense side has it mixed and checks its local side using subnet, but the remote side using single ip address.

Can anyone help with this?

Thanks in advance.

Kind regards
Marko

Yes - I learned not to use AP isolation.

Did you get this to work?

I need to implement Direct Access sometime soon so was seeing if its possible with pfSense

or am I forced to use UAG / TMG :(

Wow: I think I will check out the release candidate then!

–jason

The settings for mobile IPsec on the wiki have been confirmed to work on every platform you mention: Windows via Shrew Soft, OS X's built-in client, iOS, and Android (and others)

There are some client notes on the wiki but the most complete source of information will be the updated official pfSense book for 2.1 that will be coming out soon. It has a walk-through for configuring most of those clients, if not all of them.

It has occurred to me my own response to this thread could have been interpreted as "snarky".  I hereby retract that tone, and I will clarify what I meant.

My question stemmed from seeing "ISAKMP" on the predefined destination port range of the firewall rules.  It was clear to me I needed to allow access to ISAKMP in order to even begin an incoming ipsec session.  It just wasn't clear if that included the nat-t port.  I have since seen the nat-t entry in the port range list as "ipsec nat-t".  ONce I defined this rule, the sessions started up immediately.

This is clearly something I could have tested before I opened this thread.  I was able to verify using tcpdump at the pfsense command line.

–jason

IPsec wouldn't have anything to do with that.

Are you spoofing the MAC for the WAN interface on either side? If you are, remove that from at least one (ideally both), and reboot them to restore the proper MAC address.

If you are using CARP VIPs on either side, make sure they are using different VHIDs at each location.

That, or if you had really bad luck and actually got two NICs with the same MAC, are about the only ways that will happen.

If you aren't spoofing the MAC or using CARP VIPs, check Status > Interfaces on both and see what it says your MAC address is on either side.

permit in rule->ipsec ,then it's ok

Final testing on IPSEC issues:

I have been using 1.2.3, 2.0.3, and latest snapshot as my SOURCE at home to connect to DESTINATIONS sites ranging from pfSense 1.2.3 to 2.0.3.  No problem connecting to 1.2.3 remote sites via IPSEC.  I finally reproduced consistently that destination must be 2.0.3 (perhaps the 2.x tree even ) for IPSEC connection to eventually time out; where connection still works but no routing or name resolution occur after second reconnect attempt (after several minutes).

If my source is DD-WRT, it does not matter whether I am connecting to destination 1.2.3 or 2.0.3, it works always.  I tried all types of Shrewsoft client settings and pfSense settings (type of cipher, DPD, NAT-T, etc - results are the same).  You must restart racoon service to get back to normal.

You can reproduce this IPSEC issue by being behind 1.2.3 - to current snapshot and you connect to a remote 2.x site using Shrewsoft VPN client and waiting to reconnect 5 minutes or later - you will lose routing and obviously name resolution.  From my readings here, this not only affects IPSEC client connections, but even IPSEC VPN Site to site (I have not personally tested this scenario).  I am done testing this - I am 100% certain of this issue.