Howto set up a L2TP/IPsec VPN Dial-In Server (Part I to III)

[rolfheinrich]

1 Objective and Limitations

Utilizing net/mpd5 and security/ipsec-tools, a L2TP/IPsec VPN Dial-In Server shall be setup on FreeBSD 8.2-RELEASE. Mobile clients shall be able to connect from any IP in the world by Pre-Shared Key authentication (Wildcard PSK)

This setup has been proven to work with Mac OS X and iOS Clients. It works well with both, the server and the client, sitting behind NATs. Multiple clients may connect at the same time. However, a bug in IPsec-SA householding prevent more than one client sitting behind the same NAT, i.e. having the same public IP, from establishing connections.

I have no experience with FreeBSD and Linux clients.

I was not able to establish a connection with a Windows 7 client, since Windows seems to directly establish connections to racoon on ports 500 and 4500 and by this bypassing mpd5, which is waiting for incomming calls at port 1701.


2 Installation Procedure

Login as user root.

2.1 Build a Kernel with IPsec support

This is basically the way as outlined in Chapter 8.5 of the FreeBSD Handbook (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-building.html). Here I add IPsec support to the GENERIC kernel. My favorite editor is editors/nano. Of course, you may do all the necessary editing with any other editor.

Copy the kernel configuration of your present kernel and add the IPsec related options to it - in the following commands, replace "i386" and "GENERIC" as appropriate for your architecture and your present Kernel:
cd /usr/src/sys/i386/conf
cp GENERIC GENERIC_IPsec

Then edit the new configuration file, changing the ident parameter (quite at the top of the file) and adding the relevant IPsec options:
nano GENERIC_IPsec
ident GENERIC_IPsec
I placed the following below the first big options block:
# Options for an IPsec enabled kernel
options IPSEC
options IPSEC_NAT_T
device crypto

Build and install the new kernel. Be prepared that building the kernel will take some time.
cd /usr/src
make buildkernel KERNCONF=GENERIC_IPsec
make installkernel KERNCONF=GENERIC_IPsec

The new kernel will be copied to the /boot/kernel directory as /boot/kernel/kernel and the old kernel will be moved to /boot/kernel.old/kernel. Now restart your system.
shutdown -r now


2.2 Installation of security/ipsec-tools

Before building and installing ipsec-tools, two additional patch files shall be put into place. The first one fixes a problem of racoon frequently throwing a warning about an "unrecognized route message with rtm_type: RTM_GET".

Save the following content as /usr/ports/security/ipsec-tools/files/patch-zz-local-0.diff:
nano /usr/ports/security/ipsec-tools/files/patch-zz-local-0.diff
diff -rup srca/racoon/grabmyaddr.c srcb/racoon/grabmyaddr.c
--- src/racoon/grabmyaddr.c 2011-03-14 14:18:12.000000000 -0300
+++ src/racoon/grabmyaddr.c 2011-04-25 15:56:41.000000000 -0300
@@ -753,6 +753,7 @@ kernel_handle_message(msg)
case RTM_ADD:
case RTM_DELETE:
case RTM_CHANGE:
+ case RTM_GET:
case RTM_MISS:
case RTM_IFINFO:
#ifdef RTM_OIFINFO
@@ -768,7 +769,7 @@ kernel_handle_message(msg)
break;
default:
plog(LLV_WARNING, LOCATION, NULL,
- "unrecognized route message with rtm_type: %d",
+ "unrecognized route message with rtm_type: %d\n",
rtm->rtm_type);
break;
}

The second one patches-in Wildcard-PSK handling into racoon. This issue has been exhaustively discussed elsewhere (http://sourceforge.net/mailarchive/forum.php?thread_name=4878CA96.8080801%40aptalaska .net&forum_name=ipsec-tools-devel). The bottom-line is, that we cannot expect this to enter into racoon at any time (soon). Alternatively, mobile clients and the server could be configured using certificates - however this would make up for another Howto. Anyway here comes the patch - save the following content as /usr/ports/security/ipsec-tools/files/patch-zz-local-1.diff:
nano /usr/ports/security/ipsec-tools/files/patch-zz-local-1.diff
diff -rup srca/racoon/localconf.c srcb/racoon/localconf.c
--- src/racoon/localconf.c 2008-12-23 12:04:42.000000000 -0200
+++ src/racoon/localconf.c 2011-04-25 15:44:24.000000000 -0300
@@ -207,7 +207,8 @@ getpsk(str, len)
if (*p == '\0')
continue; /* no 2nd parameter */
p--;
- if (strncmp(buf, str, len) == 0 && buf[len] == '\0') {
+ if (strcmp(buf, "*") == 0 ||
+ (strncmp(buf, str, len) == 0 && buf[len] == '\0')) {
p++;
keylen = 0;
for (q = p; *q != '\0' && *q != '\n'; q++)

Now, build and install security/ipsec-tools.
cd /usr/ports/security/ipsec-tools
make install clean
http://forums.freebsd.org/attachment.php?attachmentid=1354&stc=1&d=1317560257


2.3 Installation of net/mpd5

mpd5 works out of the box, without any patching and without changes to the default configure options, so simply do the following:
cd /usr/ports/net/mpd5
make install clean


3 Configuration

3.1 IPsec Configuration

Racoon assumes its configuration file being at /usr/local/etc/racoon/racoon.conf, the file and the its configuration directory do not exist on fresh installation, so create the directory and save the following content to the respective configuration file - replace 192.168.0.1 by the local IP of your server:
mkdir -p /usr/local/etc/racoon
nano /usr/local/etc/racoon/racoon.conf
path pre_shared_key "/usr/local/etc/racoon/psk.txt";

listen
{
isakmp 192.168.0.1 [500];
isakmp_natt 192.168.0.1 [4500];
strict_address;
}

remote anonymous
{
exchange_mode main;
passive on;
proposal_check obey;
support_proxy on;
nat_traversal on;
ike_frag on;
dpd_delay 20;

proposal
{
encryption_algorithm aes;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group modp1024;
}

proposal
{
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group modp1024;
}
}

sainfo anonymous
{
encryption_algorithm aes,3des;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
pfs_group modp1024;
}

You might want to review the options on racoon.conf(5).

Now create the file holding the Pre-Shared Key - of course, you would replace "Ach_wie_gut,_daß_niemand_weiß,_daß_ich_Rumpelst ielzchen_heiß." with your super secret PSK pass phrase. The * is the wildcard for any IP address. If you did not patch-in Wildcard PSK handling into racoon, as suggested above, then you need to put a real IP here. In this case you may have several lines with different IPs and secrets.
nano /usr/local/etc/racoon/psk.txt
* Ach_wie_gut,_daß_niemand_weiß,_daß_ich_Rumpelst ielzchen_heiß.
Then change the access rights to a bare minimum
chmod 600 /usr/local/etc/racoon/psk.txt

Finally the file holding the security policies must be created:
nano /usr/local/etc/racoon/setkey.conf
flush;
spdflush;
spdadd 0.0.0.0/0[0] 0.0.0.0/0[1701] udp -P in ipsec esp/transport//require;
spdadd 0.0.0.0/0[1701] 0.0.0.0/0[0] udp -P out ipsec esp/transport//require;


3.2 mpd5 Configuration (s. Part II (http://forums.freebsd.org/showpost.php?p=149202&postcount=2))

[rolfheinrich]

3.2 mpd5 Configuration

Create the file holding the mpd secrets. Here you basically setup the credentials for the administrator of mpd5 and for the users who may connect to the VPN service. For example my entries look roughly like this:
nano /usr/local/etc/mpd5/mpd.secret
super "pwSuper"
rolf "pwRolf"
thomas "pwThomas"
alex "pwAlex"
anna "pwAnna"
etc "pwEtc"

Remember the login-id of the admin user (in the above example super, because you need this in the next step, i.e. creation and editing the principal configuration file. You could start with a copy of mpd.conf.sample, however this contains configurations for a lot of different operation modes of mpd5. So, I suggest, to create a new file, and copy my configuration suggestion below into it. You might want to review the file /usr/local/etc/mpd5/mpd5.conf.sample at some point in time later, though.
nano /usr/local/etc/mpd5/mpd.conf
startup:
# configure mpd users
set user super pwSuper admin
# configure the console
set console self 127.0.0.1 5005
set console open
# configure the web server
set web self 0.0.0.0 5006
set web open

default:
load l2tp_server

l2tp_server:
# Define dynamic IP address pool.
set ippool add pool_l2tp 192.168.0.150 192.168.0.199

# Create clonable bundle template named B_l2tp
create bundle template B_l2tp
set iface enable proxy-arp
set iface enable tcpmssfix
set ipcp yes vjcomp
# Specify IP address pool for dynamic assigment.
set ipcp ranges 192.168.0.1/24 ippool pool_l2tp
set ipcp dns 192.168.0.1

# Create clonable link template named L_l2tp
create link template L_l2tp l2tp
# Set bundle template to use
set link action bundle B_l2tp
# Multilink adds some overhead, but gives full 1500 MTU.
set link enable multilink
set link no pap chap eap
set link enable chap
set link keep-alive 0 0
# We reducing link mtu to avoid ESP packet fragmentation.
set link mtu 1280
# Configure L2TP
set l2tp self 192.168.0.1
set l2tp enable length
# Allow to accept calls
set link enable incoming

The above setup assumes that the local network is 192.168.0.0/24, and that the L2TP/IPsec-VPN host has the IP 192.168.0.1. Furthermore, an IP range from 192.168.0.150 to 192.168.0.199 is reserved for VPN.

"set iface enable proxy-arp" is required, if VPN clients are allowed to connect to other machines in- and outside of your local network. If VPN clients should be restricted to services of the VPN host only, then remove this setting. By default, proxy-arp is disabled.

In my setup the VPN host, hosts also the DNS server. If you have another DNS, change "set ipcp dns 192.168.0.1" accordingly. Of course, this would mean also that proxy-arp should be enabled, since otherwise, VPN clients cannot connect to another DNS.


3.3 System configurations


If VPN clients are allowed to connect to other hosts, then you need to add to /etc/sysctl.conf the following two lines:
nano /etc/sysctl.conf
net.inet.ip.forwarding=1
net.inet6.ip6.forwarding=1
Make sure, that your firewall is open for the TCP port 1701 and the UDP ports 500 and 4500.

Enable ipsec, racoon, and mpd by adding the following lines to /etc/rc.conf
nano /etc/rc.conf
ipsec_enable="YES"
ipsec_program="/usr/local/sbin/setkey"
ipsec_file="/usr/local/etc/racoon/setkey.conf"
racoon_enable="YES"
racoon_flags="-l /var/log/racoon.log"
mpd_enable="YES"


Now restart your machine.
shutdown -r now

The L2TP/IPsec-VPN server should be up and waiting for connections.

[rolfheinrich]

4. ipfw(8)/NAT for the L2TP/IPsec and PPTP Dial-In Services, all running on the same FreeBSD box

Once I wrote Part I and Part II of this Howto, my FreeBSD home server was sitting in the DMZ behind a SOHO router into the internet, and firewall/NAT was managed by the router. Recently, I connected the cable modem via USB directly to the FreeBSD box, enabled ipfw and NAT, and now it plays the role of the gateway into the internet.

Well, the switch was not that easy, and some subtleties that were not explained in the Handbook or in the relevant man pages had to be resolved before everything was working well together. I figured this would justify a separate chapter 4, making up the present new Part III of the Howto.

4.1 Adding NAT support to the Kernel

Note: This chapter 4.1 is meant to replace chapter 2.1 of Part I of this Howto.

This is basically the way as outlined in Chapter 8.5 of the FreeBSD Handbook (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-building.html). Here I add IPsec support as described in chapter 2.1 and additionally ipfw/NAT support to the GENERIC kernel. My favorite editor is editors/nano. Of course, you may do all the necessary editing with any other editor.

Login as root. Copy the kernel configuration of your present kernel and add the IPsec and ipfw/NAT related options to it. In the following commands, replace "i386" and "GENERIC" as appropriate for your architecture and your present Kernel:
cd /usr/src/sys/i386/conf
cp GENERIC GENERIC_IPsec_NAT

Then edit the new configuration file, changing the ident parameter (quite at the top of the file) and adding the relevant IPsec and ipfw/NAT options:
nano GENERIC_IPsec_NAT
ident GENERIC_IPsec_NAT
I placed the following below the first big options block:
# Options for a IPsec enabled kernel
options IPSEC
options IPSEC_FILTERTUNNEL
options IPSEC_NAT_T
device crypto
device enc

# Options for a NAT enabled kernel
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=5
options IPFIREWALL_FORWARD
options IPFIREWALL_NAT
options LIBALIAS
options IPDIVERT

IPDIVERT is not exactly needed, because I am going to setup in-kernel NAT, however, this gives me the option to do the same thing using the traditional divert method. In addition, divert is also useful for other things, like ipfw(8) tee rules.

Build and install the new kernel. Be prepared that building the kernel will take some time.
cd /usr/src
make buildkernel KERNCONF=GENERIC_IPsec_NAT
make installkernel KERNCONF=GENERIC_IPsec_NAT

The new kernel will be copied to the /boot/kernel directory as /boot/kernel/kernel and the old kernel will be moved to /boot/kernel.old/kernel. Now restart your system.
shutdown -r now


4.2 Firewall Configuration

Remember, that net/mpd5 and the security/ipsec-tools are configured to listen on the LAN interface. I wanted to keep it like this, because my LAN interface got a fixed IP address, while my WAN interface gets its IP address via DHCP from the ISP, and that may change from time to time.

While it is possible to use the /etc/dhclient-exit-hooks to script restarting mpd5 and ipsec after the public IP changed, I preferred to having mpd5 and ipsec address settings being immutable. So, I need to use NAT redirect rules for routing the respective packets from the WAN interface to the LAN interface.

I have also a VPN-PPTP dial-in server running on port 1723, therefore my firewall rules cover this one too.

Create the shell script file holding the ipfw/NAT configuration.
nano /etc/ipfw.conf; chmod ugo+x /etc/ipfw.conf

You need to replace "WAN" and "LAN" with your respective interface names. In my case, ue0 is the WAN interface and re0 is the LAN interface.

#!/bin/sh
ipfw -q flush

add="ipfw -q add"

ipfw -q nat 1 config if WAN reset\
redirect_port tcp 192.168.0.1:1723 1723\
redirect_port udp 192.168.0.1:1701 1701\
redirect_port udp 192.168.0.1:500 500\
redirect_port udp 192.168.0.1:4500 4500

# Allow everything within the LAN
$add 10 allow ip from any to any via lo0
$add 20 allow ip from any to any via LAN
$add 30 allow ip from any to any via ng*

# Catch spoofing from outside
$add 90 deny ip from any to any not antispoof in

$add 100 nat 1 ip from any to any via WAN in
$add 101 check-state

# Rules for allowing dial-in calls to the PPTP and L2TP/IPsec VPN servers
# that are listening on a LAN interface behind the NAT
$add 200 skipto 10000 tcp from any to any 1723 via WAN in setup keep-state
$add 202 skipto 10000 udp from any to any 1701 via WAN in keep-state
$add 203 skipto 10000 udp from any to any 500 via WAN in keep-state
$add 204 skipto 10000 udp from any to any 4500 via WAN in keep-state

# Rules for outgoing traffic - allow everything that is not explicitely denied
$add 1000 deny ip from not me to any 25, 53 via WAN out

# Allow all other outgoing connections
$add 2000 skipto 10000 tcp from any to any via WAN out setup keep-state
$add 2010 skipto 10000 udp from any to any via WAN out keep-state

# Rules for incomming traffic - deny everything that is not explicitely allowed
$add 5000 allow tcp from any to any 4, 80, 443, 548 via WAN in setup limit src-addr 10

# Catch tcp/udp packets, but don't touch gre, esp, icmp traffic
$add 9998 deny tcp from any to any via WAN
$add 9999 deny udp from any to any via WAN

$add 10000 nat 1 ip from any to any via WAN out
$add 65534 allow ip from any to any


Rules 10 to 30 deal with the traffic inside the LAN. ng* are the interfaces that are dynamically created by VPN connections, and of course, packets comming in or going out here shall be considered LAN packets. If you want to restrict VPN users to use certain services only, then you might want to modify rule 30.

Rule 100 sends incomming packets through the NAT, and Rule 101 checks packets against the dynamic
rule set. A crucial subtlety that is mentioned nowhere is that this rule must be numbered 101 (i.e. number of nat rule + 1). I don't know the reason for this, however, I spent hours of firewall testing, only for finding out that any other rule number than 101 did not work here for me.

Because the VPN traffic passes the NAT to another interface, i.e. has to go in and out, it cannot be simply allowed, but it has to be skipped-to the outgoing nat rule 10000.

Personnaly, I prefer the firewall style, which allows everything going-out that is not explicitely denied, and which denies everything comming-in that is not explicitely allowed. However, this is pretty much a matter of taste and there are several other ways of doing the right thing between rule numbers 1000 to 9997.

Another subtlety is, that there is not the one and only rule catching all at 9999, but there are two rules catching explicitly tcp and udp traffic, and by this leaving alone gre, esp, and icmp packets.

Rule 10000 sends outgoing packets to the NAT. Finally, the default rule 65535 of the firewall denies everything, therefore, there is the "semi-final" rule 65534 allowing everything.


4.3 Firewall Activation

In file /etc/rc.conf add the following:
nano /etc/rc.conf
firewall_enable="YES"
firewall_script="/etc/ipfw.conf"
Finally there are two more subtleties, that can be addressed by adding the following two lines to /etc/sysctl.conf:
nano /etc/sysctl.conf
net.inet.ip.fw.one_pass=0
net.inet.tcp.tso=0

Restart the server, and verify that everything is working as expected.

[jerome]

Thanks for this help to create a vpn for iOS!

But I guess I failed to follow it. I can't connect. What should I check to find my error?


2011-12-15 01:51:58: INFO: respond new phase 1 negotiation: 192.168.174.202[500]<=>192.168.174.123[500]
2011-12-15 01:51:58: INFO: begin Identity Protection mode.
2011-12-15 01:51:58: INFO: received Vendor ID: RFC 3947
2011-12-15 01:51:58: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-08
2011-12-15 01:51:58: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-07
2011-12-15 01:51:58: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-06
2011-12-15 01:51:58: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-05
2011-12-15 01:51:58: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-04
2011-12-15 01:51:58: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-03
2011-12-15 01:51:58: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
2011-12-15 01:51:58: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02

2011-12-15 01:51:58: INFO: received Vendor ID: DPD
2011-12-15 01:51:58: [192.168.174.123] INFO: Selected NAT-T version: RFC 3947
2011-12-15 01:51:58: [192.168.174.202] INFO: Hashing 192.168.174.202[500] with algo #2
2011-12-15 01:51:58: INFO: NAT-D payload #0 verified
2011-12-15 01:51:58: [192.168.174.123] INFO: Hashing 192.168.174.123[500] with algo #2
2011-12-15 01:51:58: INFO: NAT-D payload #1 verified
2011-12-15 01:51:58: INFO: NAT not detected
2011-12-15 01:51:58: [192.168.174.123] INFO: Hashing 192.168.174.123[500] with algo #2
2011-12-15 01:51:58: [192.168.174.202] INFO: Hashing 192.168.174.202[500] with algo #2
2011-12-15 01:51:58: INFO: Adding remote and local NAT-D payloads.
2011-12-15 01:51:58: [192.168.174.123] ERROR: couldn't find the pskey for 192.168.174.123.
2011-12-15 01:51:58: [192.168.174.123] ERROR: failed to process ph1 packet (side: 1, status: 4).
2011-12-15 01:51:58: [192.168.174.123] ERROR: phase1 negotiation failed.
2011-12-15 01:52:28: INFO: respond new phase 1 negotiation: 192.168.174.202[500]<=>192.168.174.123[500]
2011-12-15 01:52:28: INFO: begin Identity Protection mode.
2011-12-15 01:52:28: INFO: received Vendor ID: RFC 3947
2011-12-15 01:52:28: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-08
2011-12-15 01:52:28: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-07
2011-12-15 01:52:28: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-06
2011-12-15 01:52:28: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-05
2011-12-15 01:52:28: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-04
2011-12-15 01:52:28: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-03
2011-12-15 01:52:28: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
2011-12-15 01:52:28: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02

2011-12-15 01:52:28: INFO: received Vendor ID: DPD
2011-12-15 01:52:28: [192.168.174.123] INFO: Selected NAT-T version: RFC 3947
2011-12-15 01:53:18: ERROR: phase1 negotiation failed due to time up. 49cd238be9a1863a:8f259c9c2c44778f

[rolfheinrich]

Thanks for this help to create a vpn for iOS!

But I guess I failed to follow it. I can't connect. What should I check to find my error?


2011-12-15 01:51:58: INFO: respond new phase 1 negotiation: 192.168.174.202[500]<=>192.168.174.123[500]
...

It seems to me, that you tried to establish a VPN connection from an iOS device being in the same network as your VPN service (both having 192.168.174.xxx) - as a matter of fact this will neither work this way, nor does it make any sense, because the device is already sitting in the "private" network.

If you got a device with 3G connectivity then you might want to disconnect it from your in-house wireless-lan while testing the VPN connectivity - later, you would switch WLAN on again, and would use VPN from outside only, of course.

Best regards

Rolf

[jerome]

Yes, I did try from my local network. I'm not sure which TCP and UDP ports to open. I had previously a vpn server on mac os x, and I was able to test from my local network, so I excepted to not be an issue.

Do you know which TCP and UDP ports to open?

Thanks for your time!

[rolfheinrich]

Do you know which TCP and UDP ports to open?

For L2TP/IPsec dial-in VPN, open the UDP ports 1701, 500, and 4500.

Best regards

Rolf

[jerome]

So I still have the same error. Do you know what should I check to find my mistake?

2011-12-16 13:31:58: INFO: respond new phase 1 negotiation: 192.168.174.202[500]<=>90.84.144.59[55134]
2011-12-16 13:31:58: INFO: begin Identity Protection mode.
2011-12-16 13:31:58: INFO: received Vendor ID: RFC 3947
2011-12-16 13:31:58: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-08
2011-12-16 13:31:58: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-07
2011-12-16 13:31:58: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-06
2011-12-16 13:31:58: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-05
2011-12-16 13:31:58: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-04
2011-12-16 13:31:58: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-03
2011-12-16 13:31:58: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
2011-12-16 13:31:58: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02

2011-12-16 13:31:58: INFO: received Vendor ID: DPD
2011-12-16 13:31:58: [90.84.144.59] INFO: Selected NAT-T version: RFC 3947
2011-12-16 13:31:59: INFO: respond new phase 1 negotiation: 192.168.174.202[500]<=>90.84.144.59[55134]
2011-12-16 13:31:59: INFO: begin Identity Protection mode.
2011-12-16 13:31:59: INFO: received Vendor ID: RFC 3947
2011-12-16 13:31:59: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-08
2011-12-16 13:31:59: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-07
2011-12-16 13:31:59: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-06
2011-12-16 13:31:59: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-05
2011-12-16 13:31:59: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-04
2011-12-16 13:31:59: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-03
2011-12-16 13:31:59: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
2011-12-16 13:31:59: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02

2011-12-16 13:31:59: INFO: received Vendor ID: DPD
2011-12-16 13:31:59: [90.84.144.59] INFO: Selected NAT-T version: RFC 3947
2011-12-16 13:31:59: [192.168.174.202] INFO: Hashing 192.168.174.202[500] with algo #2
2011-12-16 13:31:59: INFO: NAT-D payload #0 doesn't match
2011-12-16 13:31:59: [90.84.144.59] INFO: Hashing 90.84.144.59[55134] with algo #2
2011-12-16 13:31:59: INFO: NAT-D payload #1 doesn't match
2011-12-16 13:31:59: INFO: NAT detected: ME PEER
2011-12-16 13:31:59: [90.84.144.59] INFO: Hashing 90.84.144.59[55134] with algo #2
2011-12-16 13:31:59: [192.168.174.202] INFO: Hashing 192.168.174.202[500] with algo #2
2011-12-16 13:31:59: INFO: Adding remote and local NAT-D payloads.
2011-12-16 13:31:59: [90.84.144.59] ERROR: couldn't find the pskey for 90.84.144.59.
2011-12-16 13:31:59: [90.84.144.59] ERROR: failed to process ph1 packet (side: 1, status: 4).
2011-12-16 13:31:59: [90.84.144.59] ERROR: phase1 negotiation failed.

[rolfheinrich]

So I still have the same error. Do you know what should I check to find my mistake?

2011-12-16 13:31:58: INFO: respond new phase 1 negotiation: 192.168.174.202[500]<=>90.84.144.59[55134]
...
...
2011-12-16 13:31:59: [90.84.144.59] INFO: Hashing 90.84.144.59[55134] with algo #2
2011-12-16 13:31:59: [192.168.174.202] INFO: Hashing 192.168.174.202[500] with algo #2
2011-12-16 13:31:59: INFO: Adding remote and local NAT-D payloads.
2011-12-16 13:31:59: [90.84.144.59] ERROR: couldn't find the pskey for 90.84.144.59.
2011-12-16 13:31:59: [90.84.144.59] ERROR: failed to process ph1 packet (side: 1, status: 4).
2011-12-16 13:31:59: [90.84.144.59] ERROR: phase1 negotiation failed.

You absolutely do not have the same error. "ERROR: couldn't find the pskey", means that your setup is almost working, and only the Pre-Shared Key, that was offered from the client to the server could not be verified/accepted.

Things to consider:

1. did you apply the wildcard-PSK patch to the ipsec-tools as mentioned in chapter 2.2 of part I of this how-to?

2. did you use exactly the same Pre-Shared Key for the client settings as you set in the file /usr/local/etc/racoon/psk.txt - see chapter 3.1 of part I of this how-to - the Pre-Shared Key is case sensitive.

Best regards

Rolf

[jerome]

I find my error: I choose a pre shared key with spaces… I removed the spaces, and now I have another error:

2011-12-16 21:52:42: INFO: Adding remote and local NAT-D payloads.
2011-12-16 21:52:42: INFO: NAT-T: ports changed to: 90.84.146.239[39936]<->192.168.174.202[4500]
2011-12-16 21:52:42: INFO: KA found: 192.168.174.202[4500]->90.84.146.239[39936] (in_use=2)
2011-12-16 21:52:53: ERROR: phase1 negotiation failed due to time up. b20141e375fa4e58:61d4c318a6d248de
2011-12-16 21:52:53: INFO: KA remove: 192.168.174.202[4500]->90.84.146.239[39936]
2011-12-16 21:53:23: ERROR: phase1 negotiation failed due to time up. aba3c83e3a127b88:cdd06785eed23ce6
2011-12-16 21:53:32: ERROR: phase1 negotiation failed due to time up. d0543eb64ae5f90f:67538ddb57b2468f
2011-12-16 21:53:32: INFO: KA remove: 192.168.174.202[4500]->90.84.146.239[39936]

[rolfheinrich]

I find my error : I choose a pre shared key with spaces… I removed the spaces, and now I have another error :

2011-12-16 21:52:42: INFO: Adding remote and local NAT-D payloads.
2011-12-16 21:52:42: INFO: NAT-T: ports changed to: 90.84.146.239[39936]<->192.168.174.202[4500]
2011-12-16 21:52:42: INFO: KA found: 192.168.174.202[4500]->90.84.146.239[39936] (in_use=2)
...

The third line of your log file excerpt is strange. Usually this one would instead look like the following:

2011-12-16 21:52:42: INFO: KA list add: 192.168.174.202[4500]->90.84.146.239[39936]

I guess, that some Key Associations from previous failed connection attempts were not purged/flushed correctly.

Please verify, whether there are any KA Zombies with the following command:

/usr/local/sbin/setkey -D

The output should be "No SAD entries." If there are some SA entries, then flush them with the following command:

/usr/local/sbin/setkey -DF

Perhaps, you might want to restart the whole VPN chain with the following command sequence:

service mpd5 restart
service ipsec restart
service racoon restart

Best regards

Rolf

[jerome]

I tried. I even rebooted my computer. Nothing changed, still the same error.

[rolfheinrich]

I tried. I even rebooted my computer. Nothing changed, still the same error.

Please can you provide the output of the following command BEFORE and AFTER a connection trial.
/usr/local/sbin/setkey -D

Is the VPN server connected via a dedicated router/firewall to the internet, or are there NAT/firewall instances running on the server itself.

In the first case, please check, whether the router allows esp packets to traverse the firewall. In the second case please check your firewall settings against my proposal in part III of this review. Note, that there is no explicit rule allowing gre, esp, and icmp, but these packet types are allowed implicitely, because rules 9998 and 9999 deny tcp/udp traffic only.

Best regards

Rolf

[jerome]

Before and after :

[root@elephant ~]# /usr/local/sbin/setkey -D
No SAD entries.
[root@elephant ~]# /usr/local/sbin/setkey -D
No SAD entries.


I enabled dmz to make sure my router would not be a problem, but it still doesn't work.


2011-12-21 23:44:37: INFO: respond new phase 1 negotiation: 192.168.174.202[500]<=>90.84.146.213[53747]
2011-12-21 23:44:37: INFO: begin Identity Protection mode.
2011-12-21 23:44:37: INFO: received Vendor ID: RFC 3947
2011-12-21 23:44:37: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-08
2011-12-21 23:44:37: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-07
2011-12-21 23:44:37: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-06
2011-12-21 23:44:37: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-05
2011-12-21 23:44:37: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-04
2011-12-21 23:44:37: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-03
2011-12-21 23:44:37: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
2011-12-21 23:44:37: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02

2011-12-21 23:44:37: INFO: received Vendor ID: DPD
2011-12-21 23:44:37: [90.84.146.213] INFO: Selected NAT-T version: RFC 3947
2011-12-21 23:44:37: [192.168.174.202] INFO: Hashing 192.168.174.202[500] with algo #2
2011-12-21 23:44:37: INFO: NAT-D payload #0 doesn't match
2011-12-21 23:44:37: [90.84.146.213] INFO: Hashing 90.84.146.213[53747] with algo #2
2011-12-21 23:44:37: INFO: NAT-D payload #1 doesn't match
2011-12-21 23:44:37: INFO: NAT detected: ME PEER
2011-12-21 23:44:37: [90.84.146.213] INFO: Hashing 90.84.146.213[53747] with algo #2
2011-12-21 23:44:37: [192.168.174.202] INFO: Hashing 192.168.174.202[500] with algo #2
2011-12-21 23:44:37: INFO: Adding remote and local NAT-D payloads.
2011-12-21 23:44:38: INFO: NAT-T: ports changed to: 90.84.146.213[33990]<->192.168.174.202[4500]
2011-12-21 23:44:38: INFO: KA list add: 192.168.174.202[4500]->90.84.146.213[33990]
2011-12-21 23:45:28: ERROR: phase1 negotiation failed due to time up. 61b1265d0a172573:5c80402522cbbc63
2011-12-21 23:45:28: INFO: KA remove: 192.168.174.202[4500]->90.84.146.213[33990]

[rolfheinrich]

I enabled dmz to make sure my router would not be a problem, but it still doesn't work.

The routers that I know do have separate settings for VPN Pass-Through. A D-Link router worked well once I enabled this setting. An older SMC router did not work by no means, though.


...
2011-12-21 23:44:38: INFO: KA list add: 192.168.174.202[4500]->90.84.146.213[33990]
2011-12-21 23:45:28: ERROR: phase1 negotiation failed due to time up. 61b1265d0a172573:5c80402522cbbc63
2011-12-21 23:45:28: INFO: KA remove: 192.168.174.202[4500]->90.84.146.213[33990]


This time, everything went OK up to the time-out error. Perhaps we get a better understanding about what's going on, when you enable verbose (debug) logging of racoon.

For temporarily putting racoon into debug mode, you could do the following:

service racoon stop
racoon -ddF

This second command starts racoon in verbose mode in the foreground, and by this way you could follow up everything in the console window while it is going on. Once you examined the output and perhaps extracted interesting parts, you can stop racoon by issuing <control>-<c>, and finally start the racoon daemon again with the following command:

service racoon start

I am sorry that I still do not have a better answer for you.

Best regards

Rolf

[tobias]

How do I enable authentication with system accounts?

I have tried:
set auth enable system-auth

but it is not working.

[rolfheinrich]

How do I enable authentication with system accounts?

I have tried:
set auth enable system-auth

but it is not working.

I have never tried this. However, I can imagine, that the problem is related to the respective description about this authentication option in the "Mpd 5.6 User Manual" at page 47 (/usr/local/share/doc/mpd5/mpd.ps).

Enables authentication against the systems password database. This options can only be used with PAP and MS-CHAP, but not with CHAP-MD5. If you intend to use this with MS-CHAP, then the passwords in the master.passwd must be NT- Hashes. You can enable this by putting :passwd_format=nth: into your /etc/login.conf, but you need at least FreeBSD 5.2.

Did you try the hint about the NT-Hashes in the master.passwd file?

I am sorry, however I fear that I cannot be of any further help in this respect. Perhaps, you might want to ask your question in the following forum: http://sourceforge.net/projects/mpd/forums/forum/44693.

Best regards

Rolf

[jerome]

Thank you very much Rolf! I think I mixed up the secret and the password in the iPhone configuration. Now it works. Just one question, is it possible to redirect all the internet traffic from the iPhone through my vpn server? I enabled the option on the iPhone, but it doesn't work.

[rolfheinrich]

Just one question, is it possible to redirect all the internet traffic from the iPhone through my vpn server? I enable the option on the iPhone, but it doesn't work.

How did you check, that it does not work?

I just tried it with my iPhone 4 (@iOS 5.0.1), and it simply does work:


without VPN, I entered in Safari, http://checkip.dyndns.org/, and at the page the current IP of my iPhone was displayed.
.
I connected to VPN (for all Data), and in Safari I refreshed the checkip page, and now it showed me the public IP address of my VPN server.

Best regards

Rolf

[ssh2]

rolfheinrich thanx for great howto. But i stick at applying patches. It rejected your diff code. %|

[rolfheinrich]

rolfheinrich thanx for great howto. But i stick at applying patches. It rejected your diff code. %|

May I ask for some more details, please? So, what exact steps resulted in what exact error messages?

In any case it is not meant, that You apply the patches manually. Provided that the patch files reside at the given location, the patches are applied automatically and without further notice when the respective port is installed. By this way, the exact patches become applied again whenever the port is upgraded.

Best regards

Rolf

[ssh2]

===> Patching for ipsec-tools-0.8.0_2
===> Applying extra patch files/patch8-utmp.diff
===> Applying FreeBSD patches for ipsec-tools-0.8.0_2
2 out of 2 hunks failed--saving rejects to src/racoon/grabmyaddr.c.rej
=> Patch patch-zz-local-0.diff failed to apply cleanly.
*** Error code 1

Stop in /usr/ports/security/ipsec-tools.
*** Error code 1

Stop in /usr/ports/security/ipsec-tools.



FreeBSD *********** 8.2-STABLE FreeBSD 8.2-STABLE #0: Sat Mar 19 19:42:38 CET 2011
root@********:/usr/obj/usr/src/sys/corequad amd64

[ssh2]

Looks like forum engine reformatting patch code. Is it possible upload files somewhere like pastebin?

Anyway, I patch it manually and ipsec-tools installed correctly.

[rolfheinrich]

Looks like forum engine reformatting patch code. Is it possible upload files somewhere like pastebin?

Anyway, i patch it manually and ipsec-tools installed correctly.

I put the respective patches into a .zip archive, and this is attached to this message (s. below).

Before I verified that the files do work at my machine:

cd /usr/ports/security/ipsec-tools
make deinstall
make install clean

===> License check disabled, port has not defined LICENSE
===> Found saved configuration for ipsec-tools-0.8.0_2
===> Extracting for ipsec-tools-0.8.0_2
=> SHA256 Checksum OK for ipsec-tools-0.8.0.tar.bz2.
===> Patching for ipsec-tools-0.8.0_2
===> Applying extra patch files/patch8-utmp.diff
===> Applying FreeBSD patches for ipsec-tools-0.8.0_2
===> ipsec-tools-0.8.0_2 depends on package: libtool>=2.4 - found
===> Configuring for ipsec-tools-0.8.0_2
...
...


Installation finished without any incident.

Best regards

Rolf

[ssh2]

Thank you!

I have another questions on configurations.
You have this: [User somewhere in NET] -> [Modem/Router with white dynamic IP] -> [VPN Server in DMZ] -> [LAN].

Can you help me with settings for this:
1) [User (ios/android/windows/osx) somewhere in NET but mostly behind NAT with gray IP (cafe, airports and other untrusted places)] -> [trusted VPN Server with white static IP and NAT for secure surfing]

2) [User (ios/android/windows/osx) somewhere in NET but mostly behind NAT with gray IP (cafe, airports and other untrusted places)] -> [trusted VPN Server with white static IP and NAT] -> [LAN in office]

[rolfheinrich]

I have another questions on configurations.
You have this: [User somewhere in NET] -> [Modem/Router with white dynamic IP] -> [VPN Server in DMZ] -> [LAN].


This is no more true, see Part III of the present Howto: (http://forums.freebsd.org/showthread.php?p=154015)

4. ipfw/NAT for the L2TP/IPsec and PPTP Dial-In Services, all running on the same FreeBSD box

Once I wrote Part I and Part II of this Howto, my FreeBSD home server was sitting in the DMZ behind a SOHO router into the internet, and firewall/NAT was managed by the router. Recently, I connected the cable modem via USB directly to the FreeBSD box, enabled ipfw and NAT, and now it plays the role of the gateway into the internet. ...

From the point of view of the FreeBSD box, the cable modem is just another network interface, therefore, the setup described in Part III (http://forums.freebsd.org/showthread.php?p=154015) can be taken as a bare two-NIC setup, one NIC into the WAN (here the cable modem ue0), and the other NIC into the LAN (here re0). In your scheme this would mean:

[User somewhere in NET] -> [dynamic IP (ue0) - ipfw/NAT - VPN (& other services) (re0)] -> [LAN]

Can you help me with settings for this:
1) [User (ios/android/windows/osx) somewhere in NET but mostly behind NAT with gray IP (cafe, airports and other untrusted places)] -> [trusted VPN Server with white static IP and NAT for secure surfing]

2) [User (ios/android/windows/osx) somewhere in NET but mostly behind NAT with gray IP (cafe, airports and other untrusted places)] -> [trusted VPN Server with white static IP and NAT] -> [LAN in office]

For the setup, described in Part III it is completely irrelevant that ue0 got a dynamic IP, so it would work exactly the same for said IP being static. So, I assume that the described settings should simply work for both of your usage cases.

However note, that I had no luck with Windows and L2TP/IPsec. For this reason, I have running also a PPTP-VPN server, as is mentioned in Part III and described here: http://forums.freebsd.org/showthread.php?p=137792.

Best regards

Rolf

[ssh2]

I don't trust that not possible use ipsec-tools on *nix with windows clients :(
Because I've seen and tested some VPN's on the internet that allow connections from windows with l2tp/ipsec enabled.

And I'm stUck on this:

2012-02-14 10:42:25: INFO: respond new phase 1 negotiation: 88.88.88.88[500]<=>1.2.3.4[500]
2012-02-14 10:42:25: INFO: begin Identity Protection mode.
2012-02-14 10:42:25: INFO: received broken Microsoft ID: MS NT5 ISAKMPOAKLEY
2012-02-14 10:42:25: INFO: received Vendor ID: RFC 3947
2012-02-14 10:42:25: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02

2012-02-14 10:42:25: INFO: received Vendor ID: FRAGMENTATION
2012-02-14 10:42:25: [1.2.3.4] INFO: Selected NAT-T version: RFC 3947
2012-02-14 10:42:25: ERROR: invalid DH group 20.
2012-02-14 10:42:25: ERROR: invalid DH group 19.
2012-02-14 10:42:25: [88.88.88.88] INFO: Hashing 88.88.88.88[500] with algo #2
2012-02-14 10:42:25: INFO: NAT-D payload #0 verified
2012-02-14 10:42:25: [1.2.3.4] INFO: Hashing 1.2.3.4[500] with algo #2
2012-02-14 10:42:25: INFO: NAT-D payload #1 doesn't match
2012-02-14 10:42:25: INFO: NAT detected: PEER
2012-02-14 10:42:25: [1.2.3.4] INFO: Hashing 1.2.3.4[500] with algo #2
2012-02-14 10:42:25: [88.88.88.88] INFO: Hashing 88.88.88.88[500] with algo #2
2012-02-14 10:42:25: INFO: Adding remote and local NAT-D payloads.
2012-02-14 10:42:25: INFO: NAT-T: ports changed to: 1.2.3.4[4500]<->88.88.88.88[4500]
2012-02-14 10:42:25: INFO: KA list add: 88.88.88.88[4500]->1.2.3.4[4500]


When I try to connect with windows 7 behind NATed office.
But when I try to connect from some place with ipad2 connection successfully.

My configs:

path pre_shared_key "/usr/local/etc/racoon/psk.txt";
log info;
padding {
maximum_length 20;
randomize off;
strict_check off;
exclusive_tail off;
}
listen {
isakmp 88.88.88.88;
isakmp_natt 88.88.88.88 [4500];
}
timer {
counter 5;
interval 20 sec;
persend 1;
phase1 30 sec;
phase2 15 sec;
}
remote anonymous {
exchange_mode main,aggressive;
doi ipsec_doi;
passive on;
generate_policy off;
proposal_check obey;
nat_traversal on;
ike_frag on;
proposal {
encryption_algorithm aes;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group modp1024;
}
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group modp1024;
}
}
sainfo anonymous {
encryption_algorithm aes;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
pfs_group 2;
}
sainfo anonymous {
encryption_algorithm 3des;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
pfs_group 2;
}


flush;
spdflush;
spdadd 0.0.0.0/0[0] 0.0.0.0/0[1701] udp -P in ipsec esp/transport//require;
spdadd 0.0.0.0/0[1701] 0.0.0.0/0[0] udp -P out ipsec esp/transport//require;

[scorpizz]

Hi all,

First of all, thank you Rolf for the great work in putting this ipsec setup online :) But - I have been fighting a bit with this ipsec setup on a fbsd FreeBSD. Maybe there is someone who can bring some light to the following problem: Iphone / Ipad is trying to make a tunnel to the fbsd FreeBSD server where the ipsec is running but get a "server is not responding".

IOS: version 5.0.1
fbsd FreeBSD: version 8.2, fresh updated ports before install.
racoon: version 0.8.0_3 (ipsec-tools)
psk: easy pwd without special charters.
user: super (as the admin user)

All the configuration files are as the ones published earlier in this Howto. Nothing is altered. The two .diff patches have been added as well to the installation. I started off from an external IP, but had this phase 1 problem. Moved the client the LAN to bypass the router just to make sure that it was not a lack of router configuration (udp ports 500, 1701 and 4500). But same error on the LAN. I know that this probably will give some other errors later on in phase 2, when outside and inside net is the same. But let's have phase 1 up and run first.

As it can be seen from the log below, it fails to find a way to do the authentication. A lorv-parm = 65001 (racoon not seems to be very happy with this.) But where to dig further down to find the cause for this invalid authentication method? The only thing that I can see is that it falls back down through the proposals, down to "low-end" encryption as the last one, so that part is working :) But with the faulty "authentication" method on every attempt.

Best regards
Gert

This is the (long) debug from racoon:

2012-02-19 23:04:43: DEBUG: ===
2012-02-19 23:04:43: DEBUG: 572 bytes message received from 172.16.0.35[500] to 172.16.0.15[500]
2012-02-19 23:04:43: DEBUG:
a32443d4 6879c6b1 00000000 00000000 01100200 00000000 0000023c 0d000124
00000001 00000001 00000118 01010008 03000024 01010000 800b0001 800c0e10
...
... [data deleted to save space]
...
80010007 800e0100 8003fde9 80020002 80040002 03000024 02010000 800b0001
702d9fe2 74cc0100 00000014 afcad713 68a1f1c9 6b8696fc 77570100
2012-02-19 23:04:43: [172.16.0.35] DEBUG2: Checking remote conf "anonymous" anonymous.
2012-02-19 23:04:43: DEBUG2: enumrmconf: "anonymous" matches.
2012-02-19 23:04:43: DEBUG: ===
2012-02-19 23:04:43: INFO: respond new phase 1 negotiation: 172.16.0.15[500]<=>172.16.0.35[500]
2012-02-19 23:04:43: INFO: begin Identity Protection mode.
2012-02-19 23:04:43: DEBUG: begin.
2012-02-19 23:04:43: DEBUG: seen nptype=1(sa)
2012-02-19 23:04:43: DEBUG: seen nptype=13(vid)
2012-02-19 23:04:43: DEBUG: seen nptype=13(vid)
2012-02-19 23:04:43: DEBUG: seen nptype=13(vid)
...
... [8 lines of repeating debug message deleted]
...
2012-02-19 23:04:43: DEBUG: seen nptype=13(vid)
2012-02-19 23:04:43: DEBUG: seen nptype=13(vid)
2012-02-19 23:04:43: DEBUG: succeed.
2012-02-19 23:04:43: INFO: received Vendor ID: RFC 3947
2012-02-19 23:04:43: [172.16.0.35] DEBUG2: Checking remote conf "anonymous" anonymous.
2012-02-19 23:04:43: DEBUG2: enumrmconf: "anonymous" matches.
2012-02-19 23:04:43: DEBUG: received unknown Vendor ID
2012-02-19 23:04:43: DEBUG:
4df37928 e9fc4fd1 b3262170 d515c662
2012-02-19 23:04:43: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-08
2012-02-19 23:04:43: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-07
2012-02-19 23:04:43: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-06
2012-02-19 23:04:43: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-05
2012-02-19 23:04:43: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-04
2012-02-19 23:04:43: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-03
2012-02-19 23:04:43: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
2012-02-19 23:04:43: [172.16.0.35] DEBUG2: Checking remote conf "anonymous" anonymous.
2012-02-19 23:04:43: DEBUG2: enumrmconf: "anonymous" matches.
2012-02-19 23:04:43: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02

2012-02-19 23:04:43: [172.16.0.35] DEBUG2: Checking remote conf "anonymous" anonymous.
2012-02-19 23:04:43: DEBUG2: enumrmconf: "anonymous" matches.
2012-02-19 23:04:43: INFO: received Vendor ID: draft-ietf-ipsra-isakmp-xauth-06.txt
2012-02-19 23:04:43: INFO: received Vendor ID: CISCO-UNITY
2012-02-19 23:04:43: INFO: received Vendor ID: DPD
2012-02-19 23:04:43: DEBUG: remote supports DPD
2012-02-19 23:04:43: [172.16.0.35] INFO: Selected NAT-T version: RFC 3947
2012-02-19 23:04:43: DEBUG: total SA len=288
2012-02-19 23:04:43: DEBUG:
00000001 00000001 00000118 01010008 03000024 01010000 800b0001 800c0e10
80010007 800e0100 8003fde9 80020002 80040002 03000024 02010000 800b0001
...
... [6 lines of data deleted]
...
03000020 07010000 800b0001 800c0e10 80010001 8003fde9 80020002 80040002
00000020 08010000 800b0001 800c0e10 80010001 8003fde9 80020001 80040002
2012-02-19 23:04:43: DEBUG: begin.
2012-02-19 23:04:43: DEBUG: seen nptype=2(prop)
2012-02-19 23:04:43: DEBUG: succeed.
2012-02-19 23:04:43: DEBUG: proposal #1 len=280
2012-02-19 23:04:43: DEBUG: begin.
2012-02-19 23:04:43: DEBUG: seen nptype=3(trns)
...
... [6 lines of repeating debug message deleted]
...
2012-02-19 23:04:43: DEBUG: seen nptype=3(trns)
2012-02-19 23:04:43: DEBUG: succeed.
2012-02-19 23:04:43: DEBUG: transform #1 len=36
2012-02-19 23:04:43: DEBUG: type=Life Type, flag=0x8000, lorv=seconds
2012-02-19 23:04:43: DEBUG: type=Life Duration, flag=0x8000, lorv=3600
2012-02-19 23:04:43: DEBUG: type=Encryption Algorithm, flag=0x8000, lorv=AES-CBC
2012-02-19 23:04:43: DEBUG: encryption(aes)
2012-02-19 23:04:43: DEBUG: type=Key Length, flag=0x8000, lorv=256
2012-02-19 23:04:43: DEBUG: type=Authentication Method, flag=0x8000, lorv=65001
2012-02-19 23:04:43: ERROR: invalid auth method 65001.
2012-02-19 23:04:43: DEBUG: transform #2 len=36
2012-02-19 23:04:43: DEBUG: type=Life Type, flag=0x8000, lorv=seconds
2012-02-19 23:04:43: DEBUG: type=Life Duration, flag=0x8000, lorv=3600
2012-02-19 23:04:43: DEBUG: type=Encryption Algorithm, flag=0x8000, lorv=AES-CBC
2012-02-19 23:04:43: DEBUG: encryption(aes)
2012-02-19 23:04:43: DEBUG: type=Key Length, flag=0x8000, lorv=128
2012-02-19 23:04:43: DEBUG: type=Authentication Method, flag=0x8000, lorv=65001
2012-02-19 23:04:43: ERROR: invalid auth method 65001.
2012-02-19 23:04:43: DEBUG: transform #3 len=36
2012-02-19 23:04:43: DEBUG: type=Life Type, flag=0x8000, lorv=seconds
2012-02-19 23:04:43: DEBUG: type=Life Duration, flag=0x8000, lorv=3600
2012-02-19 23:04:43: DEBUG: type=Encryption Algorithm, flag=0x8000, lorv=AES-CBC
2012-02-19 23:04:43: DEBUG: encryption(aes)
2012-02-19 23:04:43: DEBUG: type=Key Length, flag=0x8000, lorv=256
2012-02-19 23:04:43: DEBUG: type=Authentication Method, flag=0x8000, lorv=65001
2012-02-19 23:04:43: ERROR: invalid auth method 65001.
2012-02-19 23:04:43: DEBUG: transform #4 len=36
2012-02-19 23:04:43: DEBUG: type=Life Type, flag=0x8000, lorv=seconds
2012-02-19 23:04:43: DEBUG: type=Life Duration, flag=0x8000, lorv=3600
2012-02-19 23:04:43: DEBUG: type=Encryption Algorithm, flag=0x8000, lorv=AES-CBC
2012-02-19 23:04:43: DEBUG: encryption(aes)
2012-02-19 23:04:43: DEBUG: type=Key Length, flag=0x8000, lorv=128
2012-02-19 23:04:43: DEBUG: type=Authentication Method, flag=0x8000, lorv=65001
2012-02-19 23:04:43: ERROR: invalid auth method 65001.
2012-02-19 23:04:43: DEBUG: transform #5 len=32
2012-02-19 23:04:43: DEBUG: type=Life Type, flag=0x8000, lorv=seconds
2012-02-19 23:04:43: DEBUG: type=Life Duration, flag=0x8000, lorv=3600
2012-02-19 23:04:43: DEBUG: type=Encryption Algorithm, flag=0x8000, lorv=3DES-CBC
2012-02-19 23:04:43: DEBUG: encryption(3des)
2012-02-19 23:04:43: DEBUG: type=Authentication Method, flag=0x8000, lorv=65001
2012-02-19 23:04:43: ERROR: invalid auth method 65001.
2012-02-19 23:04:43: DEBUG: transform #6 len=32
2012-02-19 23:04:43: DEBUG: type=Life Type, flag=0x8000, lorv=seconds
2012-02-19 23:04:43: DEBUG: type=Life Duration, flag=0x8000, lorv=3600
2012-02-19 23:04:43: DEBUG: type=Encryption Algorithm, flag=0x8000, lorv=3DES-CBC
2012-02-19 23:04:43: DEBUG: encryption(3des)
2012-02-19 23:04:43: DEBUG: type=Authentication Method, flag=0x8000, lorv=65001
2012-02-19 23:04:43: ERROR: invalid auth method 65001.
2012-02-19 23:04:43: DEBUG: transform #7 len=32
2012-02-19 23:04:43: DEBUG: type=Life Type, flag=0x8000, lorv=seconds
2012-02-19 23:04:43: DEBUG: type=Life Duration, flag=0x8000, lorv=3600
2012-02-19 23:04:43: DEBUG: type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC
2012-02-19 23:04:43: DEBUG: encryption(des)
2012-02-19 23:04:43: DEBUG: type=Authentication Method, flag=0x8000, lorv=65001
2012-02-19 23:04:43: ERROR: invalid auth method 65001.
2012-02-19 23:04:43: DEBUG: transform #8 len=32
2012-02-19 23:04:43: DEBUG: type=Life Type, flag=0x8000, lorv=seconds
2012-02-19 23:04:43: DEBUG: type=Life Duration, flag=0x8000, lorv=3600
2012-02-19 23:04:43: DEBUG: type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC
2012-02-19 23:04:43: DEBUG: encryption(des)
2012-02-19 23:04:43: DEBUG: type=Authentication Method, flag=0x8000, lorv=65001
2012-02-19 23:04:43: ERROR: invalid auth method 65001.
2012-02-19 23:04:43: ERROR: no Proposal found.
2012-02-19 23:04:43: [172.16.0.35] ERROR: failed to get valid proposal.
2012-02-19 23:04:43: [172.16.0.35] ERROR: failed to pre-process ph1 packet (side: 1, status 1).
2012-02-19 23:04:43: [172.16.0.35] ERROR: phase1 negotiation failed.

[rolfheinrich]

...
I have been fighting a bit with this ipsec setup on a FreeBSD. Maybe there is someone who can bring some light to the following problem: Iphone / Ipad is trying to make a tunnel to the FreeBSD server where the ipsec is running but get a "server is not responding".
...
...


...
012-02-19 23:04:43: INFO: received Vendor ID: draft-ietf-ipsra-isakmp-xauth-06.txt
2012-02-19 23:04:43: INFO: received Vendor ID: CISCO-UNITY
...


There is probably a misunderstanding on your side. My Howto is not about setting up an IPsec tunnel connection between two dedicated endpoints, but about setting up a L2TP server that utilizes IPsec for establishing point-to-point connections in IPsec transport mode. Hence, you would not use the VPN-IPsec/Cisco client that is built-into iOS. Please try again using the VPN-L2TP/IPsec client. And as a side note, as already stated elsewhere (http://forums.freebsd.org/showpost.php?p=157861&postcount=5), L2TP/IPsec connections within the same network won't work - so please try external connections only.

Best regards

Rolf

[scorpizz]

Arrg,- sorry. I have mixed up the l2TP and IPSEC and very much focused on the IPSEC part. But after hitting the "right" buttons and fired up the L2TP tunnel on the iPhone, there is beginning to happen a lot more than before. After changing the ACL on the psk.txt file to "600", Racoon is not complaining about low security either and brings up the tunnel with no problems.

I just made a small test and it seems that there is no problem in start up the tunnel with an inside IP as well. Are having access to inside and outside world with the local LAN address.

Thanks for bringing me on the right track again :)

Best regards
Gert

[ronjns]

Hello rolfheinrich,

First of all thanks for putting up this howto. I tried to compile ipsec-tools with the 2 patches and it failed. Any comment appreciated. I'm running FreeBSD 9 Rel. Thanks!

===>>> Returning to dependency check for security/ipsec-tools
===>>> Dependency check complete for security/ipsec-tools
===> Cleaning for ipsec-tools-0.8.0_3

===> Vulnerability check disabled, database not found
===> License check disabled, port has not defined LICENSE
===> Found saved configuration for ipsec-tools-0.8.0_3
===> Extracting for ipsec-tools-0.8.0_3
=> SHA256 Checksum OK for ipsec-tools-0.8.0.tar.bz2.
===> Patching for ipsec-tools-0.8.0_3
===> Applying FreeBSD patches for ipsec-tools-0.8.0_3
2 out of 2 hunks failed--saving rejects to src/racoon/grabmyaddr.c.rej
=> Patch patch-zz-local-0.diff failed to apply cleanly.
*** Error code 1

Stop in /usr/ports/security/ipsec-tools.
*** Error code 1

Stop in /usr/ports/security/ipsec-tools.

===>>> make failed for security/ipsec-tools
===>>> Aborting update

Terminated
===>>> Installation of devel/libtool (libtool-2.4.2) complete

===>>> Deleting installed build-only dependencies


===>>> You can restart from the point of failure with this command line:
portmaster <flags> security/ipsec-tools

[suntzu]

Just modify the specific files by hand.

cd /usr/ports/security/ipsec-tools
make fetch && make extract
cd work/ipsec-tools-0.8.0/src/racoon

Edit grabmyaddr.c and localconf.c .

[rolfheinrich]

... I tried to compile ipsec-tools with the 2 patches and it failed. ...

...
===> Applying FreeBSD patches for ipsec-tools-0.8.0_3
2 out of 2 hunks failed--saving rejects to src/racoon/grabmyaddr.c.rej
=> Patch patch-zz-local-0.diff failed to apply cleanly.
*** Error code 1
...


This happened already to another fellow before, see messages #22-24 of this thread. (http://forums.freebsd.org/showpost.php?p=160729&postcount=22)

One solution would be indeed to patch the respective files by hand, however, in the course of the next update of security/ipsec-tools the patches will be vanished.

Perhaps there is a problem with producing the patch-files by copying/pasting from the present howto. Therefore, I added a .zip package containing the patches to message #24 of this thread. (http://forums.freebsd.org/showpost.php?p=160729&postcount=24) I suggest that you replace your patch-files by this ones and then try it again.

Best regards

Rolf

[ronjns]

Many hanks Suntzu and Rolf. I edited both files manually and it compiled with no error.

But I can't connect with my ipad2; made sure PSK is correct, restarted services etc but nada. :\

2012-03-27 17:05:16: INFO: respond new phase 1 negotiation: a.a.a.a[500]<=>b.b.b.b[23348]
2012-03-27 17:05:16: INFO: begin Identity Protection mode.
2012-03-27 17:05:16: INFO: received Vendor ID: RFC 3947
2012-03-27 17:05:16: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-08
2012-03-27 17:05:16: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-07
2012-03-27 17:05:16: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-06
2012-03-27 17:05:16: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-05
2012-03-27 17:05:16: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-04
2012-03-27 17:05:16: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-03
2012-03-27 17:05:16: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
2012-03-27 17:05:16: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02

2012-03-27 17:05:16: INFO: received Vendor ID: DPD
2012-03-27 17:05:16: [b.b.b.b] INFO: Selected NAT-T version: RFC 3947
2012-03-27 17:05:16: [a.a.a.a] INFO: Hashing a.a.a.a[500] with algo #2
2012-03-27 17:05:16: INFO: NAT-D payload #0 doesn't match
2012-03-27 17:05:16: [b.b.b.b] INFO: Hashing b.b.b.b[23348] with algo #2
2012-03-27 17:05:16: INFO: NAT-D payload #1 doesn't match
2012-03-27 17:05:16: INFO: NAT detected: ME PEER
2012-03-27 17:05:16: [b.b.b.b] INFO: Hashing b.b.b.b[23348] with algo #2
2012-03-27 17:05:16: [a.a.a.a] INFO: Hashing a.a.a.a[500] with algo #2
2012-03-27 17:05:16: INFO: Adding remote and local NAT-D payloads.
2012-03-27 17:05:17: [b.b.b.b] ERROR: couldn't find the pskey for b.b.b.b.
2012-03-27 17:05:17: [b.b.b.b] ERROR: failed to process ph1 packet (side: 1, status: 4).
2012-03-27 17:05:17: [b.b.b.b] ERROR: phase1 negotiation failed.

[rolfheinrich]

This looks to me like something with the Wildcard-PSK patch went wrong.

Please download the zipped patches (http://forums.freebsd.org/attachment.php?attachmentid=1433&d=1326225491) from message #24, unzip 'em, and move them to:
/usr/ports/security/ipsec-tools/files/patch-zz-local-0.diff and
/usr/ports/security/ipsec-tools/files/patch-zz-local-1.diff .

Then execute the following commands:
cd /usr/ports/security/ipsec-tools
make deinstall
make install clean
shutdown -r now

After restart, try again.

Best regards

Rolf

PS: If the file permissions of /usr/local/etc/racoon/psk.txt are too weak, then racoon would fail to load it, and racoon would report about this issue in its log file like so:
2012-03-27 08:01:42: ERROR: /usr/local/etc/racoon/psk.txt has weak file permission
2012-03-27 08:01:42: ERROR: failed to open pre_share_key file /usr/local/etc/racoon/psk.txt
2012-03-27 08:01:42: [xxx.xxx.xxx.xxx] ERROR: couldn't find the pskey for xxx.xxx.xxx.xxx.
2012-03-27 08:01:42: [xxx.xxx.xxx.xxx] ERROR: failed to process ph1 packet (side: 1, status: 4).
2012-03-27 08:01:42: [xxx.xxx.xxx.xxx] ERROR: phase1 negotiation failed.


According to your log, this is not the issue in your case. Anyway, it might be good to strip down the permissions of said file:
chmod 600 /usr/local/etc/racoon/psk.txt

I just added this recommendation to the Howto, and also attached the 2 .diff files also there.

[ronjns]

Many thanks Rolf! Please bear with me, beginner here.

I did what you suggested and the PSK error disappeared, but still my ipad2 can't connect. Could it be my firewall? I'm running PF for packet filtering, NAT and port forwarding. Log and PF rules below.

2012-03-28 11:42:42: INFO: respond new phase 1 negotiation: a.a.a.a[500]<=>b.b.b.b[1760]
2012-03-28 11:42:42: INFO: begin Identity Protection mode.
2012-03-28 11:42:42: INFO: received Vendor ID: RFC 3947
2012-03-28 11:42:42: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-08
2012-03-28 11:42:42: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-07
2012-03-28 11:42:42: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-06
2012-03-28 11:42:42: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-05
2012-03-28 11:42:42: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-04
2012-03-28 11:42:42: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-03
2012-03-28 11:42:42: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
2012-03-28 11:42:42: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02

2012-03-28 11:42:42: INFO: received Vendor ID: DPD
2012-03-28 11:42:42: [b.b.b.b] INFO: Selected NAT-T version: RFC 3947
2012-03-28 11:42:42: [a.a.a.a] INFO: Hashing a.a.a.a[500] with algo #2
2012-03-28 11:42:42: INFO: NAT-D payload #0 doesn't match
2012-03-28 11:42:42: [b.b.b.b] INFO: Hashing b.b.b.b[1760] with algo #2
2012-03-28 11:42:42: INFO: NAT-D payload #1 doesn't match
2012-03-28 11:42:42: INFO: NAT detected: ME PEER
2012-03-28 11:42:42: [b.b.b.b] INFO: Hashing b.b.b.b[1760] with algo #2
2012-03-28 11:42:42: [a.a.a.a] INFO: Hashing a.a.a.a[500] with algo #2
2012-03-28 11:42:42: INFO: Adding remote and local NAT-D payloads.
2012-03-28 11:42:42: INFO: NAT-T: ports changed to: b.b.b.b[28453]<->a.a.a.a[4500]
2012-03-28 11:42:42: INFO: KA list add: a.a.a.a[4500]->b.b.b.b[28453]
2012-03-28 11:43:32: ERROR: phase1 negotiation failed due to time up. ee2076b60744fea5:8df9d5f6768cb634
2012-03-28 11:43:32: INFO: KA remove: a.a.a.a[4500]->b.b.b.b[28453]

# MACROS
wan="tun0"
vpn="tun1"
lan="em1"
localsubnet=$lan:network
fw="{a.a.a.a/32, b.b.b.b/32}"

# PACKET NORMALIZATION
scrub in all

# TRANSLATION
nat on $wan from $localsubnet to any -> ($wan)

# REDIRECTION
rdr log on $wan proto tcp from any to ($wan) port 1723 -> 192.168.2.254
rdr log on $wan proto udp from any to ($wan) port 1701 -> 192.168.2.254
rdr log on $wan proto udp from any to ($wan) port 500 -> 192.168.2.254
rdr log on $wan proto udp from any to ($wan) port 4500 -> 192.168.2.254

# PACKET FILTERING
antispoof log quick for ($wan) # Enable anti-spoof for WAN
block in log on $wan from any to any # Block all incoming traffic to WAN
pass in log on $lan from $localsubnet to any keep state # Pass all incoming traffic to LAN w/ source of local subnet
pass in log on $wan proto tcp from $pacnetfw to ($wan) port 22 # Pass ssh traffic from * firewall to WAN
pass in log on $wan proto tcp from $pacnetfw to ($wan) port 5222 # Pass openvpn traffic from * firewall to WAN
pass out log on $wan from ($wan) to any keep state # Pass all outgoing traffic to WAN w/ source of WAN interface

pass in log on $wan from any to $localsubnet
pass in log on $wan from $localsubnet to any

pass in log on $wan proto esp from any to ($wan)
pass in log on $wan proto ipencap from any to ($wan)
pass in log on $wan proto udp from any to ($wan) port isakmp
pass in log on $wan proto udp from any to ($wan) port 4500

[rolfheinrich]

... Could it be my firewall? I'm running PF for packet filtering, NAT and port forwarding. Log and PF rules below...

The timeout error means that the peer did not respond in time, and it might well be that this happened because the response has been catched by the firewall. However, here you catched me too, since about PF, I now only that it exist.

Few things to check.

- my IPFW setup contains two nat rules, one for incoming and another one for outgoing traffic.
- is the PF rdr rule really a nat redirection rule?
- you opened udp ports 500 and 4500, but not udp port 1701

I am sorry that I do not have a better answer for you. I am an IPFW guy, which does not mean that PF is bad, it only means that I have no idea about PF

Best regards

Rolf

[suntzu]

rdr pass log on $wan proto tcp ...

[ronjns]

Thanks again Rolf and Suntzu! I tried different PF rules including those suggested but nada. :\

From racoon debug I see 'invalid packet payload'. I can be wrong, but seems like client is talking to server vice versa?

2012-03-29 11:01:51: DEBUG: begin.
2012-03-29 11:01:51: DEBUG: seen nptype=5(id)
2012-03-29 11:01:51: DEBUG: invalid length of payload
2012-03-29 11:01:52: DEBUG: ===
2012-03-29 11:01:52: DEBUG: 108 bytes message received from x.x.x.x[4500] to 192.168.y.y[4500]
2012-03-29 11:01:52: DEBUG:
43244935 f8cddf04 a062018f fbdf14e2 05100201 00000000 0000006c 0f0ab042
0ddab8d5 d2b63839 fbe20ba1 1409f703 7b42c597 43891166 ccee8c59 4030703c
c275fe61 1781bdda 38aecbaa 5e3c63db 631f7610 3f2ea4fd 59952a37 cb2f3f8d
1569375a d24dd7d5 ba9cd403
2012-03-29 11:01:52: DEBUG: begin decryption.
2012-03-29 11:01:52: DEBUG: encryption(aes)
2012-03-29 11:01:52: DEBUG: IV was saved for next processing:
2012-03-29 11:01:52: DEBUG:
cb2f3f8d 1569375a d24dd7d5 ba9cd403
2012-03-29 11:01:52: DEBUG: encryption(aes)
2012-03-29 11:01:52: DEBUG: with key:
2012-03-29 11:01:52: DEBUG:
1f582951 0446d90d 690e76b2 4a14c352 96995602 c782b01e 8d244190 a0951302
2012-03-29 11:01:52: DEBUG: decrypted payload by IV:
2012-03-29 11:01:52: DEBUG:
8ad743dc cfc6f556 4d44d67c 21a3f8e2
2012-03-29 11:01:52: DEBUG: decrypted payload, but not trimed.
2012-03-29 11:01:52: DEBUG:
a6a1dae6 9003b90d 79afff1e da5eff3b a642f43c 04561222 67f02e6e 5bb8bb51
61b16ac0 80bf504e 72e8dbf7 a144ea13 6e9b0acd a23528bb 8748c57f a2ee1c59
b2c008eb 7a2b139a 793d6e54 407ac6b3
2012-03-29 11:01:52: DEBUG: padding len=180
2012-03-29 11:01:52: DEBUG: skip to trim padding.
2012-03-29 11:01:52: DEBUG: decrypted.
2012-03-29 11:01:52: DEBUG:
43244935 f8cddf04 a062018f fbdf14e2 05100201 00000000 0000006c a6a1dae6
9003b90d 79afff1e da5eff3b a642f43c 04561222 67f02e6e 5bb8bb51 61b16ac0
80bf504e 72e8dbf7 a144ea13 6e9b0acd a23528bb 8748c57f a2ee1c59 b2c008eb
7a2b139a 793d6e54 407ac6b3
2012-03-29 11:01:52: DEBUG: begin.
2012-03-29 11:01:52: DEBUG: seen nptype=5(id)
2012-03-29 11:01:52: DEBUG: invalid length of payload
2012-03-29 11:02:01: DEBUG: 232 bytes from 192.168.y.y[4500] to x.x.x.x[4500]
2012-03-29 11:02:01: DEBUG: sockname 192.168.y.y[4500]
2012-03-29 11:02:01: DEBUG: send packet from 192.168.y.y[4500]
2012-03-29 11:02:01: DEBUG: send packet to x.x.x.x[4500]
2012-03-29 11:02:01: DEBUG: 1 times of 232 bytes message will be sent to x.x.x.x[4500]
2012-03-29 11:02:01: DEBUG:
00000000 43244935 f8cddf04 a062018f fbdf14e2 04100200 00000000 000000e4
0a000084 96d62fbe e0f871e6 255a89b4 c65ca8fc 8979d9b6 bdf1a5de 7bdb6b89
e0043dbb cfb03694 7222d5fb 0d089470 e0126b15 110ea8ad 0f07314f b5698a42
22d57f0f 1126ec0e 905ab022 38745cfa dad7bf77 c4a7e5a8 d9abd136 1a40d69d
394d4231 42f794f8 bbcbd7c5 0a433ea1 1e2686b5 b2bfcad8 c89d6dd4 512abf82
0e8335d7 14000014 bf23b485 d861d33f 7169da31 b618ede5 14000018 3e237c4b
25cd28a4 e134e1af d054a7a3 44cc1143 00000018 b5cb011f 1c3e8691 b72374ee
50437584 e0cbec33
2012-03-29 11:02:01: DEBUG: resend phase1 packet 43244935f8cddf04:a062018ffbdf14e2
2012-03-29 11:02:03: DEBUG: KA: 192.168.y.y[4500]->x.x.x.x[4500]
2012-03-29 11:02:03: DEBUG: sockname 192.168.y.y[4500]
2012-03-29 11:02:03: DEBUG: send packet from 192.168.y.y[4500]
2012-03-29 11:02:03: DEBUG: send packet to x.x.x.x[4500]
2012-03-29 11:02:03: DEBUG: 1 times of 1 bytes message will be sent to x.x.x.x[4500]
2012-03-29 11:02:03: DEBUG:
ff
2012-03-29 11:02:11: DEBUG: 232 bytes from 192.168.y.y[4500] to x.x.x.x[4500]
2012-03-29 11:02:11: DEBUG: sockname 192.168.y.y[4500]
2012-03-29 11:02:11: DEBUG: send packet from 192.168.y.y[4500]
2012-03-29 11:02:11: DEBUG: send packet to x.x.x.x[4500]
2012-03-29 11:02:11: DEBUG: 1 times of 232 bytes message will be sent to x.x.x.x[4500]
2012-03-29 11:02:11: DEBUG:
00000000 43244935 f8cddf04 a062018f fbdf14e2 04100200 00000000 000000e4
0a000084 96d62fbe e0f871e6 255a89b4 c65ca8fc 8979d9b6 bdf1a5de 7bdb6b89
e0043dbb cfb03694 7222d5fb 0d089470 e0126b15 110ea8ad 0f07314f b5698a42
22d57f0f 1126ec0e 905ab022 38745cfa dad7bf77 c4a7e5a8 d9abd136 1a40d69d
394d4231 42f794f8 bbcbd7c5 0a433ea1 1e2686b5 b2bfcad8 c89d6dd4 512abf82
0e8335d7 14000014 bf23b485 d861d33f 7169da31 b618ede5 14000018 3e237c4b
25cd28a4 e134e1af d054a7a3 44cc1143 00000018 b5cb011f 1c3e8691 b72374ee
50437584 e0cbec33
2012-03-29 11:02:11: DEBUG: resend phase1 packet 43244935f8cddf04:a062018ffbdf14e2
2012-03-29 11:02:21: ERROR: phase1 negotiation failed due to time up. 43244935f8cddf04:a062018ffbdf14e2
2012-03-29 11:02:21: INFO: KA remove: 192.168.y.y[4500]->x.x.x.x[4500]
2012-03-29 11:02:21: DEBUG: KA tree dump: 192.168.y.y[4500]->x.x.x.x[4500] (in_use=1)
2012-03-29 11:02:21: DEBUG: KA removing this one...
2012-03-29 11:02:21: DEBUG: IV freed
^C2012-03-29 11:02:26: INFO: caught signal 2
2012-03-29 11:02:26: DEBUG2: flushing all ph2 handlers...
2012-03-29 11:02:26: INFO: racoon process 4390 shutdown

[val]

Thanks Rolf for your great work!

With iPhone (iOS 5.1) VPN PSK works perfectly, but I can't to achieve the same result with android device (samsung galaxy s2). It's seems mpd5 doesn't receive anything from racoon and IPsec session expiring
IPsec-SA established: ESP/Transport XX.XX.XX.XX[500] -> YY.YY.YY.YY[500] spi=aabbccdd
After that only connection timeout on device :(

[rolfheinrich]

... With iPhone (iOS 5.1) VPN PSK works perfectly, but I can't to achieve the same result with android device (samsung galaxy s2). It's seems mpd5 doesn't receive anything from racoon and IPsec session expiring
IPsec-SA established: ESP/Transport XX.XX.XX.XX[500] -> YY.YY.YY.YY[500] spi=aabbccdd
After that only connection timeout on device :(

My understanding is, that the client needs to contact the L2TP server net/mpd5 first, which then hands-over to racoon of the security/ipsec-tools for establishing the IPsec connection. I don't know Android, but to me it seems, that it by-passes the initial L2TP login on UDP port 1701 and tries a direct negotiation with racoon on UDP port 500.

I saw an Android screenshot in the net (http://blog.brightpointuk.co.uk/sites/default/files/htc/tattoo/vpn/donut_vpn_07.png) that exhibits the possibility to enable and set the L2TP secret, i.e. the login password for mpd5. This is different from the PSK. Perhaps, you forgot to enable/set this password, and for this reason the VPN client of Android is trying its luck directly with racoon.

I never got Windows to work with L2TP/IPsec, and for this reason, I have running also a PPTP-VPN server, as is mentioned in Part III of the present Howto (http://forums.freebsd.org/showthread.php?p=154015) and described in the following forum message: http://forums.freebsd.org/showthread.php?p=137792. If you cannot get Android to working with L2TP/IPsec, then perhaps you might want to give PPTP a try.

Best regards

Rolf

[val]

Rolf, thank you for your quick reply.

Connection session for iPhone and android looks similar one to other. It's only one difference in iPhone: after line in racoon.log
IPsec-SA established: ESP/Transport XX.XX.XX.XX[500] -> YY.YY.YY.YY[500] spi=aabbccdd
in mpd.log exist following line:
Incoming L2TP packet from XX.XX.XX.XX 1701

L2TP secret field doesn't used in this process (or don't have effect)

And pptp works fine too.

Here full log from ipsec session:

2012-04-20 16:02:18: INFO: respond new phase 1 negotiation: XX.XX.XX.XX[500]<=>YY.YY.YY.YY[28420]
2012-04-20 16:02:18: INFO: begin Identity Protection mode.
2012-04-20 16:02:18: INFO: received Vendor ID: RFC 3947
2012-04-20 16:02:18: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
2012-04-20 16:02:18: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02

2012-04-20 16:02:18: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-00
2012-04-20 16:02:18: INFO: received broken Microsoft ID: FRAGMENTATION
2012-04-20 16:02:18: INFO: received Vendor ID: DPD
2012-04-20 16:02:18: [YY.YY.YY.YY] INFO: Selected NAT-T version: RFC 3947
2012-04-20 16:02:19: [XX.XX.XX.XX] INFO: Hashing XX.XX.XX.XX[500] with algo #2
2012-04-20 16:02:19: INFO: NAT-D payload #0 verified
2012-04-20 16:02:19: [YY.YY.YY.YY] INFO: Hashing YY.YY.YY.YY[28420] with algo #2
2012-04-20 16:02:19: INFO: NAT-D payload #1 doesn't match
2012-04-20 16:02:19: INFO: NAT detected: PEER
2012-04-20 16:02:19: [YY.YY.YY.YY] INFO: Hashing YY.YY.YY.YY[28420] with algo #2
2012-04-20 16:02:19: [XX.XX.XX.XX] INFO: Hashing XX.XX.XX.XX[500] with algo #2
2012-04-20 16:02:19: INFO: Adding remote and local NAT-D payloads.
2012-04-20 16:02:20: INFO: NAT-T: ports changed to: YY.YY.YY.YY[57300]<->XX.XX.XX.XX[4500]
2012-04-20 16:02:20: INFO: KA list add: XX.XX.XX.XX[4500]->YY.YY.YY.YY[57300]
2012-04-20 16:02:20: INFO: ISAKMP-SA established XX.XX.XX.XX[4500]-YY.YY.YY.YY[57300] spi:202593a6552a8869:6a6ddfa017cbd33a
2012-04-20 16:02:20: [YY.YY.YY.YY] INFO: received INITIAL-CONTACT
2012-04-20 16:02:21: INFO: respond new phase 2 negotiation: XX.XX.XX.XX[4500]<=>YY.YY.YY.YY[57300]
2012-04-20 16:02:21: INFO: Update the generated policy : 10.91.146.15/32[0] XX.XX.XX.XX/32[1701] proto=udp dir=in
2012-04-20 16:02:21: INFO: Adjusting my encmode UDP-Transport->Transport
2012-04-20 16:02:21: INFO: Adjusting peer's encmode UDP-Transport(4)->Transport(2)
2012-04-20 16:02:22: INFO: IPsec-SA established: ESP/Transport XX.XX.XX.XX[500]->YY.YY.YY.YY[500] spi=230013636(0xdb5bac4)
2012-04-20 16:02:22: INFO: IPsec-SA established: ESP/Transport XX.XX.XX.XX[500]->YY.YY.YY.YY[500] spi=160977102(0x99850ce)
2012-04-20 16:03:47: [YY.YY.YY.YY] INFO: DPD: remote (ISAKMP-SA spi=202593a6552a8869:6a6ddfa017cbd33a) seems to be dead.
2012-04-20 16:03:47: INFO: purging ISAKMP-SA spi=202593a6552a8869:6a6ddfa017cbd33a.
2012-04-20 16:03:47: INFO: deleting a generated policy.
2012-04-20 16:03:47: INFO: purged IPsec-SA spi=230013636.
2012-04-20 16:03:47: INFO: purged ISAKMP-SA spi=202593a6552a8869:6a6ddfa017cbd33a.
2012-04-20 16:03:47: INFO: ISAKMP-SA deleted XX.XX.XX.XX[4500]-YY.YY.YY.YY[57300] spi:202593a6552a8869:6a6ddfa017cbd33a
2012-04-20 16:03:47: INFO: ISAKMP-SA deleted XX.XX.XX.XX[4500]-YY.YY.YY.YY[57300] spi:202593a6552a8869:6a6ddfa017cbd33a
2012-04-20 16:03:47: INFO: KA remove: XX.XX.XX.XX[4500]->YY.YY.YY.YY[57300]

[rolfheinrich]

val,

After googling a little bit, I found the following thread on the issue:

http://code.google.com/p/android/issues/detail?id=23124.

Seems, that I cannot be of any help here, but the android team has to get their act together.

For the time being, at least PPTP is confirmed to work. I am sorry, that I do not have a better answer for you.

Best regards

Rolf

[val]

Thank you Rolf,
I agree that this is bug in android.

[jr]

Hey Rolf,

Slightly off the topic of IPSec here but I'm hoping you can assist given your experience with MPD. It seems that the mailing list for MPD on SourceForge was removed quite some time back and I'm struggling to find any other mailing lists or user groups that seem to be active on this stuff.

We’re looking for some insights on an error message we’re getting from MPD and the only reference we found to this error message in Google was on a Russian site even then it was hard to tell if there was anything by way of constructive input/feedback.

So you have some background, what we’re trying to do is use OpenL2TP to generate some PPP over L2TP traffic such that we can test using MPD to do tunnel switching. The intent here is to use MPD to get around a problem with one of our carrier partners whereby we need to terminate multiple L2TP tunnels from them (for multiple wholesale clients) but they don’t seem willing or able to provide a different tunnel name for each client. So we’re planning to use MPD to switch the PPP traffic to a new tunnel and hand it off to our Cisco LNS’s.

We’re running OpenL2TP 1.8 with PPP 2.4.5 on CentOS 6.2 64-Bit. Open L2TP and PPP were both compiled from source. They seem to be operating correctly (OpenL2TP tests as per the doco work fine) however whe we point the L2TP at the MPD instance we strike problems with the following output/error:


Incoming L2TP packet from 27.121.90.5 51937
L2TP: Control connection 0x801c90e10 27.121.90.1 1701 <-> 27.121.90.5 51937 connected
L2TP: Incoming call #1 via connection 0x801c90e10 received
[LNS1-3] L2TP: Incoming call #1 via control connection 0x801c90e10 accepted
[LNS1-3] Link: Matched action 'forward "LAC1"'
[R-LNS1-3] Rep: INCOMING event from LNS1-3 (0)
L2TP: Initiating control connection 0x801c91110 27.121.90.4 0 <-> 27.121.90.8 1701
[LNS1-3] L2TP: Call #1 connected
L2TP: Control connection 0x801c91110 27.121.90.4 46904 <-> 27.121.90.8 1701 connected
ppp_l2tp_initiate: Operation not supported
[R-LNS1-3] Rep: DOWN event from LAC1-4 (1)
[LNS1-3] L2TP: Call #1 terminated locally
[R-LNS1-3] Rep: DOWN event from LNS1-3 (0)
[R-LNS1-3] Rep: Shutdown
[LAC1-4] Link: SHUTDOWN event
[LAC1-4] Link: Shutdown
[LNS1-3] Link: SHUTDOWN event
[LNS1-3] Link: Shutdown
L2TP: Control connection 0x801c91110 terminated: 0 (No application/session timer expired)
L2TP: Control connection 0x801c90e10 terminated: 0 (no more sessions exist in this tunnel)
L2TP: Control connection 0x801c91110 destroyed
L2TP: Control connection 0x801c90e10 destroyed


MPD is running on FreeBSD 8.2 amd64 as this seemed to be about the best supported platform for it. Initially testing looked good but once we fire up the PPP over L2TP traffic we hit this error.

We have an urgent need to get this working and would appreciate any assistance you can offer. There doesn't seem to be much available in terms of doco / insights and it doesn't look like there are a lot of options for this sort of thing in a software based platform.

Cheers,

Jules

[rolfheinrich]

... I'm struggling to find any other mailing lists or user groups that seem to be active on this stuff.

The MPD-Forum on sourceforge (http://sourceforge.net/projects/mpd/forums/forum/44693) is quite active.

... We’re looking for some insights on an error message we’re getting from MPD and the only reference we found to this error message in Google was on a Russian site even then it was hard to tell if there was anything by way of constructive input/feedback.

I found that thread also, and Alexander Motin, who responded at that time, and who is one of the developers and also a quite active responder on said forum, gave some advises (http://translate.google.com/translate?hl=de&sl=ru&tl=en&u=http%3A%2F%2Fwww.frozenfido.ru%2Fru.unix.bsd%2F8 906734c9007.html), i.e. searching the net for LAC / LNS or at least have a look into the mpd manual (http://mpd.sourceforge.net/doc5/mpd.html). I have to admit, that I have never dealt with access concentration into a LNS. I can tell you that Alexander helped me in the other forum to get me L2TP/IPsec to working, and the advise to consult the manual, even if it sounds harsh somehow - note, he did not say RTFM - is a good one. The mpd manual is really worth a thorough reading, I was able to clarify almost all my doubts by the way of reading the respective chapters.

... We’re running OpenL2TP 1.8 with PPP 2.4.5 on CentOS 6.2 64-Bit. Open L2TP and PPP were both compiled from source. They seem to be operating correctly (OpenL2TP tests as per the doco work fine) however whe we point the L2TP at the MPD instance we strike problems with the following output/error:


...
ppp_l2tp_initiate: Operation not supported
...


Seems as if OpenL2TP is trying to initiate something in a way that is not supported by net/mpd5. OpenL2TP claims to be the most complete L2TP client/server, which would mean that the other systems in the crowd are not that complete. Perhaps it might be possible to configure OpenL2TP down to this crowd level.

Best regards

Rolf

[jr]

Hey Rolf,

Many thanks for the quick reply mate.

I appreciate you pointing out the current SourceForge forum for MPD. We hadn't found that one yet in our travels and you're right, it seems to be pretty active/current.

Actually, as luck would have it, we seem to have worked out our problem. We were trying to bind a couple of LNS IP's from our upstream carrier to a single instance of mpd and this was the cause of the issues. Initially we dropped it back to one and then massaged the config to get it workign with both.

Now it's working nicely with OpenL2TP in our test environment and we've also been able to test it with a real end client. We're just about to add some more end clients so we can start to load it up but it was performing nicely with 8-10 Mbps running over it and there was very little latency added as traffic traversed our MPD instance. I'm keen to see how the CPU utilisation scales. I had yet to install VMware Tools into FreeBSD and will do this and see if I can enable on of the accelerated network adapter types. I trust that will give us more efficiency in terms of the ratio b/w traffic and CPU utilisation.

Happy to share more of the details if it's of interest.

Best Regards,

Jules

[rolfheinrich]

Hallo Jules!


...
Actually, as luck would have it, we seem to have worked out our problem.
...
Happy to share more of the details if it's of interest.


Glad to hear, that you were able to solve the problem. I am sure, that many people (me included) would appreciate a detailed writing-up, i.e. sort of Howto setup a LAC/LNS architecture using mpd5 on FreeBSD.

Best regards

Rolf