@FRUENAGEL: Also tried this. L2tp over Ipsec with Windows builtin client and PFSense will not work under most conditions. The cause is here: https://redmine.pfsense.org/issues/475 Indeed this makes Pfsense quite useless for all, who want to provide a secure dialin connection for windows roadwarrior clients without installation of additional client software.  This is sad. Nearby: it works technically, if the client's ip is known and used as an identifier for the PSK. Regards Frank Ok, thanks for confirming this for me. I did get PPTP working on Windows 7, although I can access lan machines only by IP address and not by name but it's better than nothing. Yes, I'm aware that PPTP has been cracked and is no longer secure. Yes, we're typical Winblows users and we will take convenience over security :) We have a mix of Win and Mac users and at some point they'll want to use their phones and tablets too so as the poor IT guy I'm not looking forward to what's to come (hehe, actually I'm, billable hours and blame everything on buggy software). Anyway, I'll explore using Openvpn and Shrewsoft client but for now we just need a tunel for couple traveling guys (one Windows and one Mac) so they can get to the LAN. I'm sure the good people at pfSense will work out the kinks with VPN at some point. I've learned not to expect from any software everything working as I'd like it to and I'm very happy with pfSense as a router and firewall (been using it for many years now).

Though IP-range to CIDR converters are available via various web pages, they're often cumbersome to use – especially if you have a lot of stuff to convert. Here's some scripts I built for doing command-line/scripted IP range to CIDR conversions using code from pfSense (1 shell script, 2 PHP scripts and a ReadMe): http://www.derman.com/Resources/Blogs/IPrangeToCIDRscripts.zip If you have a large number of IP ranges to convert, put them into a text file and cat/pipe the text-file contents through the PHP script that takes entries from STDIN.  I regularly process tens of thousands of entries because I use these scripts/commands inside other scripts that I use to automatically assemble block lists from various Internet sources which are daily loaded into pfSense as aliased URL Tables to support various "bad-guy" IP-blocking rules (at some point I'll put together a blog on the blocking stuff).

@boujid: as @eureka tutorial worked, it gave me the idea to change some parameters in my initial configuration (mutual-psk only) so i decided to test different combinations : Policy Generation PFS/VPNClient;Proposal Checking;NAT Traversal;Result –-----------------------------;-----------------;-------------;------ Default/auto;Default;Enable;"Tunnel up ; Traffic Down" unique/unique;Default;Enable;"Tunnel up ; Traffic Down" unique/unique;Default;force/force-rfc;"Tunnel up ; Traffic up" Default/auto;Default;force/force-rfc;"Tunnel up ; Traffic Down" require/require;Default;force/force-rfc;"Tunnel up ; Traffic up" require/auto;Default;force/force-rfc;"Tunnel up ; Traffic Down" on/auto;Default;force/force-rfc;"Tunnel up ; Traffic Down" on/shared;Default;force/force-rfc;"Tunnel up ; Traffic Down" Default/shared;Default;force/force-rfc;"Tunnel up ; Traffic Down" Default/require;Default;force/force-rfc;"Tunnel up ; Traffic up" Default/unique;Default;force/force-rfc;"Tunnel up ; Traffic up" require/unique;Default;force/force-rfc;"Tunnel up ; Traffic up" unique/require;Default;force/force-rfc;"Tunnel up ; Traffic up" require/shared;Default;force/force-rfc;"Tunnel up ; Traffic Down" unique/shared;Default;force/force-rfc;"Tunnel up ; Traffic Down" unique/auto;Default;force/force-rfc;"Tunnel up ; Traffic Down" Default/require;Default;force/enable;"Tunnel up ; Traffic up" Default/require;Default;enable/force-rfc;"Tunnel up ; Traffic Down" in brief, the old configuration present in PFS 1.2.3 can work in PFS 2.1 if and only if this two points are satisfied : point 1 NAT Traversal in PFS must be configured as "force" , VPN client can be configured as "force-rfc" or "enable" point 2 Policy Generation in PFS must be either Default, unique or require while the same policy in the vpn client (shrew soft) must be either unique or require there is other combinations not tested, but i believe that the above two points are mandatory i dont know what changed in the racoon daemon, but for sure, the parameters of NAT Traversal dont behave in version 2.1 as in the version 1.2.3 i hope that my journey will be beneficial for other persons that's all folks ! Boujld, Very good investigation! I will do some testing myself and see if there is possibly a bug or something. I do know that in version 1.2.3 NAT-T was only kind of working and caused some issues at random. It is likely that it has changed since then. I will finalize the tutorial I re-wrote and get it online this weekend, making special note of your post on the requirements for nat-t/etc. I will look into also doing a few others with different methods like what you are requesting. Thanks! -E

Advanced > Firewall/NAT > Disable all auto-added VPN rules I checked the box and saved settings.  I already had added an IPv4 allow all rule with logging enabled.  The tunnel establishes almost immediately with this change. This confirms (if it wasn't already evident) there is a firewall rule problem at play in my set up. When diffing /tmp/rules.debug with /tmp/rules.debug.old, I see only the VPN rules which are all set to "reply-to" and "route-to" the WAN gateway (which isn't necessary as both nodes are in the same "WAN subnet").  Maybe had I thrown another device in the middle to do the routing this would not have happened, but regardless of that fact, this is still a realistic scenario (VPN tunnels between two hosts in the same subnet). Advanced > Firewall/NAT > Disable reply-to on WAN rules Doesn't take effect as far as I can tell (at least not on the auto-created VPN rules which I re-enabled).  Reverting the change (unchecking the checkbox) and diffing rules.debug and rules.debug.old show only the USER_RULEs are affected (though all rules probably should be affected). If I copy the /tmp/rules.debug to another file in /tmp/ and tear out the (route-to|reply-to) keywords with vi … and reload the rules with pfctl, my tunnels magically initiate from either end (and establish). # different per host and depends on other rules, but the gist 154,157s/ reply-to ( em0 10.9.8.1 ) //g 154,157s/ route-to ( em0 10.9.8.1 ) //g It also appears there is a bug where the last phase1 that is saved is "latched on to" or used (I have duplicates due to testing, so I expect that is why it picks the wrong duplicate over the new one). And another apparent bug (on my production box) which is really messed up. ISAKMP is UDP 500 and NAT-T is UDP 4500 … # IPSec Logs from when I click the play button on Status > IPSec page Feb 25 20:52:34 racoon: [Self]: INFO: X.X.X.X[4500] used for NAT-T Feb 25 20:52:34 racoon: [Self]: INFO: X.X.X.X[4500] used as isakmp port (fd=9) Feb 25 20:52:34 racoon: [Self]: INFO: X.X.X.X[500] used for NAT-T Feb 25 20:52:34 racoon: [Self]: INFO: X.X.X.X[500] used as isakmp port (fd=10) # racoon.conf listen {         adminsock "/var/db/racoon/racoon.sock" "root" "wheel" 0660;         isakmp X.X.X.X [500];         isakmp_natt X.X.X.X [4500]; } _This is what I've found thus far. I would greatly appreciate it if someone would test this scenario to double check._

I reply to myself. The issue with pfSense is the lack of control on how the SPD are generated. I succeeded to get my initial setup with a standard FreeBSD using ipsec-tools (aka Racoon 1) and MPD5. Just in case, don't loose your time trying to use raccoon 2, almost required options are not yet implemented.

I upgraded my side to version 2.1.0 and it is connecting fine now.

@jimp: In your IPsec firewall rules, make sure you are passing to a destination of the post-NAT IP, 192.168.3.x Is there somewhere I can read in the docs on what order firewall rules and nat rules, etc. are applied/evaluated? Thank you.

It seems to finally be working.  The 100.100 network "knew" to route through the 10 network to reach the 172 network.  I knew nothing about the 100 network other than my 10 network was connected to the FE2 port on their cisco router.  I ended up watching the firewall log on the 10 network and discovered that the 100 network was "appearing" on my 10.26 network as being on a completely different network (26.67…..)  I created a manual NAT outbound rule for packets on the LAN side for that network, and translated them to the interface address.  That seems to have done the trick.  I still need to verify it with the vendor tomorrow, but I can see activity on the target server.    I'd like to find out exactly what the vendor is doing on the other side of that router.  Even though it is working, I'm not certain I really understand the mechanics behind why it is working.    Thanks for your suggestions.

Ok, so those are both pfSense hosts at either end. Does the tunnel establish between the two hosts? @AYSMAN: SITE A PHASE 2 Mode:                                Tunnel IPV4 Local Network:                  LAN Subnet Remote Network:              192.168.235.0/24 (Local Network of SITE B) Protocol:                            ESP Encryption Algorithm:      3DES Hash Algorithm:                SHA1 PFS Key Group:                2(1024Bit) Lifetime                            3600 […snipped...] SITE B PHASE 2 Mode:                                Tunnel IPV4 Local Network:                  LAN Subnet Remote Network:              192.168.235.0/24 (Local Network of SITE A) Protocol:                            ESP Encryption Algorithm:      3DES Hash Algorithm:                SHA1 PFS Key Group:                2(1024Bit) Lifetime                            3600 In your information, the subnet information in both phase2 sections is identical.  That will not work. In order to create traffic that will establish and/or traverse your IPSec tunnel… From the webui: Status > IPSec > Click the button to establish the tunnel OR Diagnostics > Ping > Change interface to LAN From the shell: ping -S <local_lan_ip><remote_lan_ip>That command above is sourcing packets from the LAN IP you specify (so it is sent across the tunnel) and sending it to the remote LAN.</remote_lan_ip></local_lan_ip>

Look at the usage of NAT onto ipsec on 2.1 that will help with your problem.

Well support for cisco style radius attributes is there. For active directory attirbutes is not there presently so i do not think you can do that with pfsense unless you use IAS.

I give up untill someone comes with something to try, I can't figure it out ….  :'(

I figured it out. Thanks for the help…..

In the current implementation, no. If you want multiple separate security levels for mobile users, you'll need OpenVPN

Here you go: [2.1-RELEASE][admin@sipsense.localdomain]/root(3): grep esp /tmp/rules.debug pass  in  quick  on $WAN reply-to ( rl1 24.118.172.1 ) inet proto esp  from 63.238.x.x to any keep state  label "USER_RULE: Allow ESP from XRD ASA" pass out on $WAN  route-to ( rl1 24.118.172.1 )  proto esp from any to 63.238.x.x keep state label "IPsec: XRD ASA - outbound esp proto" pass in on $WAN  reply-to ( rl1 24.118.172.1 )  proto esp from 63.238.x.x to any keep state label "IPsec: XRD ASA - inbound esp proto"