IPSec/L2TP with pfSense 2.2
-
Hi all,
Same problem here. IPSec tunnel was successfully established with the client but after that there's no l2tp connection.
I've tried many things (as Phoenix and pfSalmon) with no success. -
Got the same problem. IPSec connects but nothing shows up in l2tp-logs. The Client trys and throws error 809 after a while.
Is there any solution yet?
-
Looks like there may be an issue when the client itself is behind NAT. Is that the case for everyone seeing problems?
-
Looks like there may be an issue when the client itself is behind NAT. Is that the case for everyone seeing problems?
It's not true.
The IPSec/L2TP VPN can be established on iOS, no matte it behind NAT or 3G/4G network (actually it's same as behind NAT). But it couldn't work on Win7/8.1 client. -
OK, that's consistent with one of our other tests. The problem seems to be Windows Clients with NAT. iOS seemed to connect OK either way.
-
For me, everything is connecting fine.
However, the address that is entered for Remote Address Range is 192.168.32.0. This is the IP being handed out when I connect. which, of course, doesn't work.
This is not the address I entered. When ever I try to change the address to something like 192.168.32.15, for example, pfSense changes it back to 192.168.32.0.
Am I assuming correctly this is not the desired behavior?
If this is not the correct behavior how to I fix this?
How can I get it to accept an address that ends in something other than .0?Thanks in advance!
-
Fix your subnet mask. It will align the clients to start at the beginning of the entered "subnet".
Since it's a fake subnet anyhow, .0 should work in that context, does it not?
-
As I configure a road warrior setup my clients are always behind NAT. Please note, that I tested Win8.1 and Android - neither works.
-
Looks like there may be an issue when the client itself is behind NAT. Is that the case for everyone seeing problems?
Yes, it is behind NAT.
-
Looks like there may be an issue when the client itself is behind NAT. Is that the case for everyone seeing problems?
Yes, it is behind NAT.
Than you should look at the sent identity from the mobile clients.
Before racoon was tolerant on this identity if the remoteip matched either the one sent by clients or the one retrieved from packet itself. -
I've tried to configure Android 4.1.2 L2TP https://doc.pfsense.org/index.php/L2TP/IPsec_on_Android#L2TP_Setup
Nothing works. If you use IPSEC identifier, then android forces to use aggresive mode and connection fails, because you can not enable aggresive mode in strongwan when no xauth enabled and… you can not use IPSEC without identifier if you don't use xauth. Epic...
Does somebody else running IPSEC with android 4.1 on 2.2?EDIT:
Solution
strongswan app + generated certificate with additional Alternative Name "DNS" that must be similar to Common Name. And connection type is
EAP-TLS, peer identifier is the same as Common Name in Cert. -
Hi there,
I, too, spent the last two days trying to set this up properly, unfortunately with little success.
Like pfSalmon and others I get a working IPSec connection (and it detects my LAN IP behind NAT) but L2TP won't respond at all, leading to a 809 error on windows.
I did everything like in the docs tutorial and added the floating filter (made no difference)
Unfortunately I can't contribute any info that might help to find the solution either, I'm pretty much a noob in that area..
Hope someone will find a fix soon :)
-
I'm also having the same issue. My VPN clients can connect, but they can't access anything inside the network.
-
I hope this doesn't get too messy, as there are people here who get a L2TP connection but can't communicate with local clients while others (like me) get an IPSec connection but no L2TP connection.
On that Note, I noticed something "weird looking" in the L2TP Raw Logs:
Feb 22 17:22:11 l2tps: process 34657 started, version 4.4.1 (root@pfsense-22-amd64-builder 12:58 18-Nov-2014) Feb 22 17:22:11 l2tps: Label 'startup' not found Feb 22 17:22:11 l2tps: [l2tp0] using interface l2tp0 Feb 22 17:22:11 l2tps: L2TP: waiting for connection on 0.0.0.0 1701
Is this "correct" behavior?
-
I am having the same issue across the board with getting ipsec going. I followed this to the letter:
https://doc.pfsense.org/index.php/L2TP/IPsecbut still cant get a tunnel established. The closest i get is possibly the ipsec tunnel being established but no l2tp.
machines tested:
windows 2008 server, android 5.0.1, android 4.4.4
any help would be appreciated as i have been trying to get this going for about a week now.
-
Any updates on this? did anyone find a solution or will this issue be addressed in a future update?
EDIT: More weird stuff.. after experimenting with IKEv2 n other VPN settings, AES doesn't work as encryption method for Phase 1 IPsec anymore, only 3DES does, and I'm very confident that it did beforehand…
-
https://doc.pfsense.org/index.php/L2TP/IPsec
I just fallowed this and did a little different configuration. Now it works on my iPhone/iPad and my MacbookAir(Yosemite 10.10.1).
In Phase 1, iOS only support DH group 2, not 14.
If i change the DH group to 14 (MODP_2048), I'll receive a mismatch error in logs.Mar 3 09:49:39 charon: 10[CFG] received proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024 Mar 3 09:49:39 charon: 10[CFG] configured proposals: IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
So it shows the iOS/OSX supports AES(128/256) or 3DES with DH group 2 in Phase 1.
If a Windows 2008 R2 client connects , the log shows this:
Mar 3 10:17:54 charon: 13[CFG] received proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/ECP_384, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/ECP_256, IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
It shows the Windows client support AES256 with DH group 14 or 3DES with DH group 2/14. The hash algorithmnly only support SHA1.
An Android 4.1.1 client connects the log is like this:
Mar 3 10:23:47 charon: 08[CFG] received proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
The Android client supports AES(128/256)/3DES/DES , with DH group 2.
At last I configured the Phase 1 use 3DES, SHA1, DH group 2, it works for iOS/Android/MacOS X/Windows. It's less security but that's enough for me.
If your iPhone can connect but you can't access any website, just fallow that guide add a floating firewall rule. It'll works.
But now if the Android and Windows connects, in Status>IPsec it shows a client connected and established a IPsec tunnel, but about half minute the client shows connect failed. And there's no L2TP logs.
Then I tried a Windows client with public IPv4 address, it connected successful.
It seems Android and Windows can't dial L2TP behind NAT now.
Hope someone will find a fix for this. -
Hi
I found a potential fix for the Windows clients here: http://support.microsoft.com/kb/926179 I used the number "2" setting, and rebooted my Win 8.1 client, the reg hack changes the NAT-T behavior.
However, I can't test it because like many others here in this post, I cannot get any activity on the L2TP server. IPsec connects fine but then nothing. I am following the guide and have quintuple checked the settings. There must be a rule (NAT-T?) that needs to go somewhere to allow UDP 1701 traffic to go some where. Is there an architecture diagram somewhere so I can understand the rule set flow from WAN to IPsec to L2TP VPN when NAT-T is invoked? I feel very close to a solution for Windows behind NAT. TIA.
If you want to you can cut and paste this into a .reg file and then import (Win7-8.1 only):
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent]
"AssumeUDPEncapsulationContextOnSendRule"=dword:00000002
-
Having not being able to get what I need from a VPN using the instructions for MSCHAPv2, I decided to go back to attempting a L2TP/IPsec VPN.
Using various suggestions found in this thread, I am able to successfully establish a connection using iOS 8x.
I have 2 problems now
Problem #1
I am unable to access anything both inside my network or out outside (internet). Attempting communications to any network device via IP or DNS fails. And, simply attempting to browse to something like google.com, also fails.
I have checked and rechecked my floating FW rules they're all good.
I have checked and rechecked my FW rules for IPsec & L2TP interfaces, also, all good.Packet capture reveals nothing (admittedly, I may not be doing this part correctly)
Problem #2
The settings I had to use to get the iOS devices connected do not allow Windows 7/8.1 devices to connect at all. Which doesn't mean much since I can't get them to connect no matter what the Phase 1&2 settings are.
I have also checked and rechecked my settings on the Win clients, all are good.
I, as well as many others, I'm sure, were waiting for 2.2 so that we could have L2TP/IPsec VPN. It's a shame so many seem to not be able to get it to work.
Because of some of the VPN clients I need to support, OpenVPN isn't an option.
-
Just to toss the salad some here:
My issues are as follows:
I've set up IPSec With IKE and it Works like a charm on my mobile phone. I can Access internal web-servers and such, when i'm Connected and the internet is provided from 4G.
What I cant get to work is my Laptop With VPN Connect software from Shrew Soft. The Client Connects, I get the welcome Message, but I can't Access local servers. This happens when the Laptop is Connected to my mobile phone on Wi-Fi hotspot With shared internet over 4G.