@craggy: I've tried everything I can think of but no way can I get this to work. no matter what I do I cant get a second phase 2 to come up when it uses a subnet that doesn't directly exist on a wan or lan interface. is this a bug in pfsense 2.1 or am I doing something stupid? please can someone help, I really need to get this working. Another way to do this would be to use a larger subnet on the first Phase 1 of the WAN. I.E. You have 3 networks: 192.168.100.0/24 A 192.168.101.0/24 B 192.168.102.0/24 C So when you setup the phase 2 for A to B, on the B side you set the remote WAN to 192.168.0.0/16

Worked perfectly! A thousand thanks for your help! Kind regards Beach

First of all turn OFF the Windows firewall, then test something.

Hmm, that looks like a fairly dead end… Well, i'll have to go with openVPN then. Thanks.

Hi Daniel, please clarify your setup. Do you have a dual WAN box? Do you have WAN1 as default gateway and want IPSEC tunnels to go through WAN2? Regards,   Corrado

**FIXED ** I got the issue on 2 tunnels out of a dozen. Apart log flood, the tunnels get stuck after a few weeks. The affected tunnels originated from the same ISP. I fixed the issue disabiling NAT-T. UDP encapsulation of IPSEC (NAT-T) kicks in as soon as NAT is detected, despite many SOHO routers can forward ESP when properly configured. I suggest to always try IPSEC without NAT-T first. If it works you save 8 bytes / packet (no extra UDP header) and lower the chances to get packets fragmentations (seems IPSEC MTU is not adjusted subtracting 8 bytes when using NAT-T). Regards,   Corrado

Hi Silvertip, if I understand you mean that when I disable a tunnel, save changes, re-enable and save changes again I'm actually bouncing all tunnels twince. If so I agree it is faster to restart Racoon once.

Did you create a firewall rule on the pFsense on the IPSec tab?

In the pfSense cert manager you can export the ca+cert+key as a .p12 natively. It's the third down arrow ("v") in the cert manager list. The author of the Shrew Soft client (mgrooms) used to be a pfSense dev and last I heard he's pretty responsive and willing to fix things.

You just set the phase 2 to match the node IPs on either end. In 2.1 you can do the specify an address to NAT your internal node to below where you enter the real ip.

You do not need public cert I don't see in your environment AD CS, and this is bad configuration AD+VPN+File Sharing (for users files) on one server, also physical AD this is very bad solution, today you can clone AD! Use microsoft tool CMAK, with this tool you can create Installer for VPN user connection and all needed scripts, adding certs, registry modifications, routes etc. Users just need to install that. Don't see a problem using pfSense + Srv 2012 VPN L2TP/IPSec + Adding registry keys using CMAK (Connection Manager Administration Kit) Or pfSense + Srv 2012 + SSTP VPN + Adding Root CA certificate using CMAK (Connection Manager Administration Kit) CMAK http://technet.microsoft.com/en-us/library/cc726035.aspx In server 2012 R2 you can setup Work Folders, this is exactly for your needs…

@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.