@jimp: make sure the client(s) are also set to use NAT-T, and make sure nothing is blocking UDP/4500 between the clients and the firewall Clients are iOS 6 devices on 3G, so no in-depth settings there. Firewall is open: https://www.evernote.com/shard/s12/sh/659a1b61-92b4-470e-8d3c-f6c40616ce51/24d11db24ce72f1e9383166dfdcdb1e4/deep/0/Screenshot%202/4/13%204:00%20PM.jpg

You can't use NAT and IPsec together unless you're on a recent 2.1 snapshot.

@Phonebuff: I know the PPTP is not going to be an issue but would the IPSec tunnel conflict with a GRE port forward ? GRE is a protocol, not a port.  Provided you permit GRE ingress, the mapping should be handled by NAPT. I have to admit that I've never had a PPTP server behind pfSense (pfS does the VPN thing very well all by itself), but from my experience of this on Cisco AdvSec/K9 installations: Port forward 1723 from the WAN IP to the internal PPTP server and GRE pass any-to-LAN on the WAN ingress rules. Hope that helps

A better trace. [2.0.2-RELEASE][admin@pfsense.localdomain]/root(11): racoon -F -v -f /var/etc/racoon.conf Foreground mode. 2013-01-26 18:06:35: INFO: @(#)ipsec-tools 0.8.0 (http://ipsec-tools.sourceforge.net) 2013-01-26 18:06:35: INFO: @(#)This product linked OpenSSL 0.9.8n 24 Mar 2010 (http://www.openssl.org/) 2013-01-26 18:06:35: INFO: Reading configuration from "/var/etc/racoon.conf" 2013-01-26 18:06:35: INFO: ###.###.###.###[4500] used for NAT-T 2013-01-26 18:06:35: INFO: ###.###.###.###[4500] used as isakmp port (fd=7) 2013-01-26 18:06:35: INFO: ###.###.###.###[500] used for NAT-T 2013-01-26 18:06:35: INFO: ###.###.###.###[500] used as isakmp port (fd=8) 2013-01-26 18:06:36: INFO: IPsec-SA request for 205.251.233.121 queued due to no phase1 found. 2013-01-26 18:06:36: INFO: initiate new phase 1 negotiation: ###.###.###.###[500]<=>205.251.233.121[500] 2013-01-26 18:06:36: INFO: begin Identity Protection mode. 2013-01-26 18:06:36: INFO: IPsec-SA request for 205.251.233.122 queued due to no phase1 found. 2013-01-26 18:06:36: INFO: initiate new phase 1 negotiation: ###.###.###.###[500]<=>205.251.233.122[500] 2013-01-26 18:06:36: INFO: begin Identity Protection mode. 2013-01-26 18:06:36: INFO: received Vendor ID: DPD 2013-01-26 18:06:36: INFO: received Vendor ID: DPD 2013-01-26 18:06:36: INFO: ISAKMP-SA established ###.###.###.###[500]-205.251.233.121[500] spi:1ee34d6e99489278:653e1800428e4e9e 2013-01-26 18:06:36: INFO: ISAKMP-SA established ###.###.###.###[500]-205.251.233.122[500] spi:f1ff1e51933d7b6a:7c457666c24352b8 2013-01-26 18:06:37: INFO: initiate new phase 2 negotiation: ###.###.###.###[500]<=>205.251.233.121[500] 2013-01-26 18:06:37: INFO: initiate new phase 2 negotiation: ###.###.###.###[500]<=>205.251.233.122[500] 2013-01-26 18:06:37: INFO: IPsec-SA established: ESP ###.###.###.###[500]->205.251.233.121[500] spi=61646745(0x3aca799) 2013-01-26 18:06:37: INFO: IPsec-SA established: ESP ###.###.###.###[500]->205.251.233.121[500] spi=70676050(0x4366e52) 2013-01-26 18:06:37: INFO: IPsec-SA established: ESP ###.###.###.###[500]->205.251.233.122[500] spi=223058808(0xd4b9b78) 2013-01-26 18:06:37: INFO: IPsec-SA established: ESP ###.###.###.###[500]->205.251.233.122[500] spi=4066502990(0xf261e94e)

I don't recall exactly how they had it set. Details are in the howto here on the forum somewhere.

Many people already are. It's perfectly stable for most deployments. There are still a couple rough edges here and there but not ones that most people would hit.

thanks your quick respone! i will survey another way to setup l2tp/ipsec vpn. thank you very much.

This worked wonderfully! Thank you, this has been driving me mad for so long.

It can work but you need to make changes to both IPsec tunnels so that they include networks for Host 1 and Host 2.

The screens are largely the same between them. Just match up the phase 1 and 2 settings. http://doc.pfsense.org/index.php/VPN_Capability_IPsec http://doc.m0n0.ch/handbook/ipsec.html

Yes, the necessary firewall rules are added automatically.

No I gave up and setup an openvpn box in my VPC on the same box running the NAT

I have a PPPOe WAN, so that may very well be the problem. Will try the 2.0.3 sometime. Thanks. Lex

Hi I am back again. I've been using IPSEC in tunnel mode for a while but I am giving transport another go. I have tried again and I cannot get IPSEC transport mode to come up. I have disabled IPSEC ESP and am just using AH for the time being. I have allowed both protocols on the WAN interface (ESP & HA) from the public IP address of each side to "any" (as well as ICMP from either sides) Prefer old IPSEC SAs is OFF I have: IP: IPv4 INTERFACE: WAN REMOTE GATEWAY: PUBLIC IP OF OTHER SIDE AUTHENTICATION PROTOCOL: Mutual PSK NEGOTIATION: Agressive MY IDENTIFIER: My IP Address PEER IDENTIFIER: Peer IP Address PRESHARED KEY: <psk>(COPY & PASTED, THEY ARE THE SAME) POLICY GENERATION: Default PROPOSAL CHECKING: Default ENCRYPTION ALGORITHM: 3DES HASH ALGORITHM: SHA384 DH KEY GROUP: 2(1024 bit) LIFETIME: 28800 NAT TRAVERSAL: DISABLE DEAD PEER: UNCHECKED And for Phase 2: MODE: TRANSPORT PROTOCOL: AH HASH ALGORITHMS: MD5 PFS KEY GROUP: OFF LIFETIME: 86400 AUTOMATICALLY PING HOST: BLANK I know in IPSEC it is CRITICAL to make sure sides match, so I have ensured. I've deleted the SPD on both sides and restart racoon and still comes up with "error" under Status > IPSEC. No obvious errors in the logs (Ive googled just about everything in there) GRE is up and running, with OSPF over it. I can ping/access my remote subnets, but it breaks when I turn on IPSEC. I'd be really grateful for any ideas!</psk>

If you are in the same subnet, the WAN rules have reply-to on them which sends the data back via the gateway. That breaks what you're trying to do. You can disable reply-to in the advanced options on the firewall/NAT tab.

Thanks for the explanation. For those who have the same problem, I've solved it with a workaround, for now. I've: assigned a virtual IP (192.168.2.1) on LAN interface set up apposite rules on firewall/NAT section (included Manual Outbound NAT) added a new address (for eg. 192.168.2.5) on the network card of internal Windows machine and a new gateway 192.168.2.1 (with a higher metric than default to not interfere with the previous state) in the Windows machine set up a new permanent route to 10.1.0.0/16 net via 192.168.2.1 gateway It works!