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

rolfheinrich · #1 October 2nd, 2011, 14:05

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

Code:

ident           GENERIC_IPsec

I placed the following below the first big options block:

Code:

# 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

Code:

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

Code:

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

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

Code:

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_Rumpels tielzchen_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

Code:

* Ach_wie_gut,_daß_niemand_weiß,_daß_ich_Rumpelstielzchen_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

Code:

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)

rolfheinrich · #2 October 2nd, 2011, 14:48

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

Code:

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

Code:

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
Code:
```
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

Code:

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 · #3 November 10th, 2011, 21:02

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

Code:

ident           GENERIC_IPsec_NAT

I placed the following below the first big options block:

Code:

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

Code:

#!/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

Code:

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

Code:

net.inet.ip.fw.one_pass=0
net.inet.tcp.tso=0

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

jerome · #4 December 15th, 2011, 01:55

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?

Code:

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 · #5 December 15th, 2011, 11:22

Quote:

Originally Posted by 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?

Code:

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 · #6 December 16th, 2011, 10:39

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 · #7 December 16th, 2011, 11:19

Quote:

Originally Posted by jerome

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 · #8 December 16th, 2011, 13:33

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

Code:

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 · #9 December 16th, 2011, 17:00

Quote:

Originally Posted by jerome

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

Code:

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 · #10 December 16th, 2011, 22:01

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

Code:

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 · #11 December 17th, 2011, 00:14

Quote:

Originally Posted by jerome

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

Code:

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:

Code:

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 · #12 December 19th, 2011, 22:38

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

rolfheinrich · #13 December 20th, 2011, 10:53

Quote:

Originally Posted by jerome

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 · #14 December 21st, 2011, 23:48

Before and after :

Code:

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

Code:

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 · #15 December 22nd, 2011, 21:15

Quote:

Originally Posted by jerome

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.

Quote:

Originally Posted by jerome

Code:

...
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 · #16 December 28th, 2011, 14:10

How do I enable authentication with system accounts?

I have tried:

Code:

set auth enable system-auth

but it is not working.

rolfheinrich · #17 December 29th, 2011, 01:24

Quote:

Originally Posted by tobias

How do I enable authentication with system accounts?

I have tried:

Code:

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

Quote:

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 · #18 January 6th, 2012, 10:22

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 · #19 January 6th, 2012, 14:17

Quote:

Originally Posted by jerome

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 · #20 January 9th, 2012, 22:37

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

rolfheinrich · #21 January 10th, 2012, 02:58

Quote:

Originally Posted by ssh2

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 · #22 January 10th, 2012, 11:51

Code:

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

Code:

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 · #23 January 10th, 2012, 14:17

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 · #24 January 10th, 2012, 20:58

Quote:

Originally Posted by 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.

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

Code:

===>  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 · #25 January 12th, 2012, 10:52

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]

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
connect to server with l2tp	mfaridi	Web & Network Services	6	January 13th, 2011 09:55
MacOS X VPN client vs. FreeBSD IPSec VPN Server	dyp	Networking	2	January 8th, 2011 08:33
[Solved] ipsec vpn - gif_if connection problem	da1	Networking	1	October 16th, 2010 08:33
L2tp/ipsec	wong_baru	Networking	2	May 23rd, 2010 14:36
VPN over IPsec on FreeBSD 8.0	vodvorezlaya	Networking	2	December 30th, 2009 15:43

The Following 11 Users Say Thank You to rolfheinrich For This Useful Post:
amao (October 3rd, 2011), amr (March 29th, 2013), carp (January 8th, 2013), Crivens (January 17th, 2013), dkorzhevin (August 12th, 2012), gkontos (October 2nd, 2011), jerome (December 16th, 2011), pbd (January 8th, 2013), toongya (February 18th, 2012), xtaz (November 26th, 2012), zeissoctopus (December 15th, 2011)

The Following 8 Users Say Thank You to rolfheinrich For This Useful Post:
amao (October 3rd, 2011), carp (January 8th, 2013), dkorzhevin (August 12th, 2012), snerpton (January 1st, 2013), srivo (February 5th, 2013), toongya (February 18th, 2012), xtaz (November 26th, 2012), zeissoctopus (December 15th, 2011)

The Following 4 Users Say Thank You to rolfheinrich For This Useful Post:
carp (January 8th, 2013), dkorzhevin (August 12th, 2012), toongya (February 18th, 2012), zeissoctopus (December 15th, 2011)

The Following User Says Thank You to rolfheinrich For This Useful Post:
toongya (February 18th, 2012)

The Following 2 Users Say Thank You to rolfheinrich For This Useful Post:
HarryE (December 16th, 2011), jerome (December 16th, 2011)

The Following User Says Thank You to rolfheinrich For This Useful Post:
jerome (January 6th, 2012)