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

Rolf,

Thanks for this great How-to! I still have one small issue. Even if I'm able to see and connect on all machine on my remote network. I can't connect to those machine using their name. I need to connect to them using the IP adress. So time machine doesn't recognize 192.168.2.23 as is original Time Capsule drive. Any idea to solve that?

Him using your first type of configuration. My VPN server is in the DMZ of the router.

Thanks,

Serge
 
srivo said:
... Even if I'm able to see and connect on all machine on my remote network. I can't connect to those machine using their name. I need to connect to them using the IP adress. So time machine doesn't recognize 192.168.2.23 as is original Time Capsule drive. Any idea to solve that. ...

I do not own a Time Capsule, however, I assume, that it announces its services to the local network by multicast DNS, i.e. Bonjour. Mulitcast packages are limited to the LAN, and net/mpd5 does not forward them, so the VPN clients cannot take notice of the announced service names.

If you want to connect to the local machines from a remote VPN client by name, then you could setup a local name server on your FreeBSD machine that hosts the VPN server, and make the client use this name server.

Another possible option would be to edit the file /etc/hosts on your Mac, and put a name/IP pair for your Time Capsule in there.

Finally, are you sure, that Time Capsule does not accept access by IP? I setup a Time Machine volume on my FreeBSD server using net/netatalk and I can use this by IP address (and also Bonjour from within the LAN).
 
Rolf,

I was trying to avoid using IP because I think for time machine it will be a different drive and I will loose my actual backup. Adding IP/name in /etc/hosts look to be the best solution so far.

But even if I see the Time Capsule and Time Machine detect it, It as not been able to connect to the drive. I will need to investigate further on that!

Thanks
 
srivo said:
... I was trying to avoid using IP because I think for time machine it will be a different drive and I will loose my actual backup. ...

I can access my Time Machine volume on my FreeBSD server either by IP or by name, and in each case the Mac client recognizes and accepts its designated backup. My understanding is, that on backup-store-creation the drive UUID of the client is stored into the backup store, and as long as this doesn't change, the client will connect to the backup by either way. I cannot talk for Time Capsule, however, I would be very surprised if it works differently in this respect.

srivo said:
But even if I see the Time Capsule and Time Machine detect it, It as not been able to connect to the drive. ...

Can you connect to other AFP volumes via VPN?
 
It work when I use my FreeBSD for time machine but I didn't suceded using Time Capsule. I will need to try again!
 
jef said:
PR kern/146190 seems to still be open, but the patches linked in http://www.freebsd.org/cgi/query-pr.cgi?pr=146190#reply2 are on a URI that apparently no longer has DNS providing an address.

Yes, it seems they have gone.

Are these patches still required for 9.1-STABLE to have multiple clients of the VPN with NAT?

I cannot tell anything on 9.1-STABLE, I am working with 9.1-RELEASE.

If so, is there another source for the patches?

The patches that were present at the link you have given were quite old, however, I could still apply them to /usr/src/sys and security/ipsec-tools. Only ipsec_natt.v4.diff generated a lot of warnings about "offset lines". In addition I added also the changes suggested on http://lists.freebsd.org/pipermail/freebsd-stable/2012-May/067416.html. So at that time, I decided to generate a clean new patch which contains all changes in one .diff-file and which can be applied to /usr/src/sys without warnings. I attached this file named ipsec-patches.diff to this message.

Make a backup, then:
# cd /usr/src
# patch -p1 < /path/to/ipsec-patches.diff

Then rebuild the kernel.

I attached to this message also the complete set (including the already known ones) of the patches for the security/ipsec-tools in one .zip-archive. The content of this archive has to be added into /usr/ports/security/ipsec-tools/files/.

Then rebuild security/ipsec-tools.

Please report back your experience with 9.1-STABLE.
 

Attachments

  • ipsec-patches.diff
    12.4 KB · Views: 759
  • ipsec-tools-patches.zip
    4.7 KB · Views: 711
dkorzhevin said:
Can anyone please tell if these patches have already been included upstream?

Experiment:

$ mkdir -p head-base/sys
$ cd head-base
$ svn co [url=http://svn0.us-east.freebsd.org/base/head/sys/netinet]http://svn0.us-east.freebsd.org/base/head/sys/netinet[/url] sys/netinet
$ svn co [url=http://svn0.us-east.freebsd.org/base/head/sys/netipsec]http://svn0.us-east.freebsd.org/base/head/sys/netipsec[/url] sys/netipsec
$ patch -p1 < /path/to/ipsec-patches.diff

Result:
Code:
patching file sys/netinet/tcp_input.c
Hunk #1 succeeded at 695 (offset -10 lines).
patching file sys/netipsec/esp_var.h
Hunk #1 FAILED at 77.
1 out of 1 hunk FAILED -- saving rejects to file sys/netipsec/esp_var.h.rej
patching file sys/netipsec/ipsec_input.c
patching file sys/netipsec/key.c
Hunk #2 succeeded at 1314 (offset -1 lines).
Hunk #3 succeeded at 2958 (offset -6 lines).
Hunk #4 succeeded at 3084 (offset -6 lines).
Hunk #5 succeeded at 3507 (offset -6 lines).
Hunk #6 succeeded at 3789 (offset -17 lines).
Hunk #7 FAILED at 4111.
Hunk #8 succeeded at 4709 (offset -18 lines).
Hunk #9 succeeded at 4800 (offset -18 lines).
Hunk #10 succeeded at 5148 (offset -18 lines).
Hunk #11 succeeded at 5250 (offset -18 lines).
Hunk #12 succeeded at 5466 (offset -18 lines).
Hunk #13 succeeded at 5531 (offset -18 lines).
1 out of 13 hunks FAILED -- saving rejects to file sys/netipsec/key.c.rej
patching file sys/netipsec/keydb.h
patching file sys/netipsec/xform_esp.c
Hunk #1 FAILED at 78.
1 out of 1 hunk FAILED -- saving rejects to file sys/netipsec/xform_esp.c.rej

Conclusion:

The majority, i.e. 12 out of 15 hunks of the patch can be still applied to the latest sources. The offsets indicate only that the respective source file was changed at other (perhaps unrelated) places. I examined the 3 rejects, and they are caused by some differences in the context lines of the hunks. This only means, that these changes need to be done manually.

If anything of the patch would have been applied already to the sources, then those hunks would have failed with the message "Reversed (or previously applied) patch detected!".

Short answer:

Nothing of the patches is included upstream.
 
In a PM, @brehtacz wrote me:

I've conected Windows 7 to FreeBSD box (9.1 and 9.2-RC3).

Problem is that afrer disconnection I have to wait ~10 min before I succesfuly conect again. What is/could be a problem, is there are any cimers to set in config? Sysctl tuning?

I could reproduce the problem. When a Windows client disconnects, for some reason only the SA for the outgoing connection is removed, and the SA for the incoming connection turns to stale, and prevents the client from connecting again. The workaround is to tear down any stale SA's by a script:

nano /usr/local/etc/racoon/tear_down.sh
Code:
#!/bin/sh

REMOTE_NAT="`echo $REMOTE_ADDR | /usr/bin/sed "s/\./\\\\\./g"`\[$REMOTE_PORT\]"
REMOTE_SPI="`/usr/local/sbin/setkey -D | /usr/bin/sed -n "N;/.*$REMOTE_NAT.*spi=/{s///;s/(.*//;p;}"`"

while [ "$REMOTE_SPI" != "" ] ; do

   echo "tear down SA: delete $REMOTE_ADDR[$REMOTE_PORT] $LOCAL_ADDR[$LOCAL_PORT] esp-udp $REMOTE_SPI;" >> /var/log/racoon.log
   echo "delete $REMOTE_ADDR[$REMOTE_PORT] $LOCAL_ADDR[$LOCAL_PORT] esp-udp $REMOTE_SPI;" | /usr/local/sbin/setkey -c
 
   REMOTE_SPI="`/usr/local/sbin/setkey -D | /usr/bin/sed -n "N;/.*$REMOTE_NAT.*spi=/{s///;s/(.*//;p;}"`"

done
chmod ugo+x /usr/local/etc/racoon/tear_down.sh

Then in /usr/local/etc/racoon/racoon.conf add two script entries. For the record, here comes my whole racoon.conf:
Code:
path pre_shared_key "/usr/local/etc/racoon/psk.txt";
path certificate    "/usr/local/etc/racoon/certs";

listen
{
	isakmp		 192.168.x.y [500];
	isakmp_natt	 192.168.x.y [4500];
	strict_address;
}

remote anonymous
{
	exchange_mode    main;
	certificate_type x509 "service.crt" "service.key";
	ca_type          x509 "ca.crt";
	verify_cert      off;
	my_identifier    asn1dn;
	passive          on;
	generate_policy	 unique;
	proposal_check   obey;
	support_proxy    on;
	nat_traversal    on;
	ike_frag         on;
	dpd_delay        10;
	dpd_retry         2;
	dpd_maxfail       2;
	script           "/usr/local/etc/racoon/tear_down.sh" phase1_down;
	script           "/usr/local/etc/racoon/tear_down.sh" phase1_dead;

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

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

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

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

Perhaps you need to remove the certificate stuff and the proposals for RSA signature authentication.
 
Last edited by a moderator:
Thank you @rolfheinrich for tips about IPsec etc..

What I managed: Windows 7 (behind NAT) connects to FreeBSD 9.2-RC3. For FreeBSD I've used patches from post http://forums.freebsd.org/showthread.php?p=228384#post228384

For Windows 7 I've added and changed in the Registry the AssumeUDPEncapsulationContextOnSendRule key (set to 2).

I used your script (post http://forums.freebsd.org/showpost.php?p=231620&postcount=86).

Everything works, but why in my racoon.log I can see something like this:
Code:
Start VPN Connection
2013-09-03 13:40:07: INFO: respond new phase 1 negotiation: xx.xx.xx.53[500]<=>xx.xx.xx.50[57229]
2013-09-03 13:40:07: INFO: begin Identity Protection mode.
2013-09-03 13:40:07: INFO: received broken Microsoft ID: MS NT5 ISAKMPOAKLEY
2013-09-03 13:40:07: INFO: received Vendor ID: RFC 3947
2013-09-03 13:40:07: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02

2013-09-03 13:40:07: INFO: received Vendor ID: FRAGMENTATION
2013-09-03 13:40:07: [xx.xx.xx.50] INFO: Selected NAT-T version: RFC 3947
2013-09-03 13:40:07: ERROR: invalid DH group 20.
2013-09-03 13:40:07: ERROR: invalid DH group 19.
2013-09-03 13:40:07: [xx.xx.xx.53] INFO: Hashing xx.xx.xx.53[500] with algo #2
2013-09-03 13:40:07: INFO: NAT-D payload #0 verified
2013-09-03 13:40:07: [xx.xx.xx.50] INFO: Hashing xx.xx.xx.50[57229] with algo #2
2013-09-03 13:40:07: INFO: NAT-D payload #1 doesn't match
2013-09-03 13:40:07: INFO: NAT detected: PEER
2013-09-03 13:40:07: [xx.xx.xx.50] INFO: Hashing xx.xx.xx.50[57229] with algo #2
2013-09-03 13:40:07: [xx.xx.xx.53] INFO: Hashing xx.xx.xx.53[500] with algo #2
2013-09-03 13:40:07: INFO: Adding remote and local NAT-D payloads.
2013-09-03 13:40:07: INFO: NAT-T: ports changed to: xx.xx.xx.50[50706]<->xx.xx.xx.53[4500]
2013-09-03 13:40:07: INFO: KA list add: xx.xx.xx.53[4500]->xx.xx.xx.50[50706]
2013-09-03 13:40:07: INFO: ISAKMP-SA established xx.xx.xx.53[4500]-xx.xx.xx.50[50706] spi:4337188e650fd11a:1aeab936af7b4376
2013-09-03 13:40:07: INFO: respond new phase 2 negotiation: xx.xx.xx.53[4500]<=>xx.xx.xx.50[50706]
2013-09-03 13:40:07: INFO: Update the generated policy : xx.xx.xx.50/32[1701] xx.xx.xx.53/32[1701] proto=udp dir=in
2013-09-03 13:40:07: INFO: Adjusting my encmode UDP-Transport->Transport
2013-09-03 13:40:07: INFO: Adjusting peer's encmode UDP-Transport(4)->Transport(2)
2013-09-03 13:40:07: INFO: IPsec-SA established: ESP/Transport xx.xx.xx.53[500]->xx.xx.xx.50[500] spi=160493464(0x990ef98)
2013-09-03 13:40:07: INFO: IPsec-SA established: ESP/Transport xx.xx.xx.53[500]->xx.xx.xx.50[500] spi=233019322(0xde397ba)
-----------------------------------------------------

Stop VPN Connection
2013-09-03 13:41:03: INFO: deleting a generated policy.
2013-09-03 13:41:03: INFO: purged IPsec-SA proto_id=ESP spi=233019322.
2013-09-03 13:41:03: ERROR: pfkey X_SPDDELETE failed: Invalid argument
2013-09-03 13:41:03: ERROR: pfkey X_SPDDELETE failed: Invalid argument
2013-09-03 13:41:03: INFO: ISAKMP-SA expired xx.xx.xx.53[4500]-xx.xx.xx.50[50706] spi:4337188e650fd11a:1aeab936af7b4376
2013-09-03 13:41:03: INFO: ISAKMP-SA deleted xx.xx.xx.53[4500]-xx.xx.xx.50[50706] spi:4337188e650fd11a:1aeab936af7b4376
2013-09-03 13:41:03: INFO: KA remove: xx.xx.xx.53[4500]->xx.xx.xx.50[50706]
tear down SA: delete xx.xx.xx.50[50706] xx.xx.xx.53[4500] esp-udp 160493464;
2013-09-03 13:41:03: INFO: unsupported PF_KEY message REGISTER
2013-09-03 13:41:03: ERROR: no iph2 found: ESP xx.xx.xx.50[500]->xx.xx.xx.53[500] spi=160493464(0x990ef98)
-----------------------------------------------------

Questions:
  1. Why
    Code:
    2013-09-03 13:40:07: INFO: NAT-D payload #1 doesn't match
    if there is a password defined in psk.txt? Password is defined (* - patched IPSec, and for specific IP).
  2. Code:
    2013-09-03 13:41:03: ERROR: pfkey X_SPDDELETE failed: Invalid argument
    What does it mean? What's wrong?
  3. Code:
    2013-09-03 13:40:07: ERROR: invalid DH group 20 (19)

Thanks,
Tomas.
 
Last edited by a moderator:
brehtacz said:
...
Everything works, but why in my racoon.log I can see something like this:
Code:
...
2013-09-03 13:41:03: INFO: deleting a generated policy.
2013-09-03 13:41:03: INFO: purged IPsec-SA proto_id=ESP spi=233019322.
2013-09-03 13:41:03: ERROR: pfkey X_SPDDELETE failed: Invalid argument
2013-09-03 13:41:03: ERROR: pfkey X_SPDDELETE failed: Invalid argument
2013-09-03 13:41:03: INFO: ISAKMP-SA expired xx.xx.xx.53[4500]-xx.xx.xx.50[50706] spi:4337188e650fd11a:1aeab936af7b4376
2013-09-03 13:41:03: INFO: ISAKMP-SA deleted xx.xx.xx.53[4500]-xx.xx.xx.50[50706] spi:4337188e650fd11a:1aeab936af7b4376
2013-09-03 13:41:03: INFO: KA remove: xx.xx.xx.53[4500]->xx.xx.xx.50[50706]
tear down SA: delete xx.xx.xx.50[50706] xx.xx.xx.53[4500] esp-udp 160493464;
2013-09-03 13:41:03: INFO: unsupported PF_KEY message REGISTER
2013-09-03 13:41:03: ERROR: no iph2 found: ESP xx.xx.xx.50[500]->xx.xx.xx.53[500] spi=160493464(0x990ef98

Well, the tear down script is working as it should. I see the final error "... no iph2 found ...", on my VPN server as well in the course of deleting the stale SA, and my best educated guess is, that this ESP link has been removed just before in the course of the regular disconnection sequence. So, I tend to simply ignore this error message.

brehtacz said:
Questions:
1. Why
Code:
2013-09-03 13:40:07: INFO: NAT-D payload #1 doesn't match
if there is a password defined in psk.txt? Password is defined (* - patched IPSec, and for specific IP).

I see this as well, even when connecting with iOS or Mac OS X clients. Only in these cases payloads #0 doesn't match and payloads #1 are verified. I guess, that this is simply sort of a log of the negotiation sequence between clients and server.

brehtacz said:
2.
Code:
2013-09-03 13:41:03: ERROR: pfkey X_SPDDELETE failed: Invalid argument

I see this as well, and this started to occur after I applied the kernel patches. There seems to be a mismatch now between the key management in the kernel and its accessors in the ipsec-tools. Actually because of this, the uniquely created SPD's are not removed in the course of the disconnection sequence. This is not exactly nice, but also not that mission critical, since the SPD's are removed automatically after life-time expiration of 3600 s.

I didn't come to investigate this further.

brehtacz said:
3. What does it mean? What's wrong?
Code:
2013-09-03 13:40:07: ERROR: invalid DH group 20 (19)

This is not a big deal. The maximum Diffie-Hellmann group that the racoon knows is 18. Windows starts trying with 20, then 19, and negotiates on 18, i.e. the DH group that both know.
 
For those wondering, it is perfectly possible to connect to a FreeBSD machine with a windows client using this howto. I've got it working with Mpd5 + Racoon on Freebsd 9.1 by using roughly this guide. I can connect with windows clients by using the shrewsoft vpn client. Works perfectly. All clients connect from behind a NAT. The FreeBSD server is also behind a NAT.
 
sukosevato said:
For those wondering, it is perfectly possible to connect to a FreeBSD machine with a windows client using this howto. I've got it working with Mpd5 + Racoon on Freebsd 9.1 by using roughly this guide.

Are you referring to the mere howto (posts #1-3 only) of this thread, or did you apply the complete set of ipsec-tool and kernel patches revealed in post #82?

sukosevato said:
I can connect with windows clients by using the shrewsoft vpn client. Works perfectly. All clients connect from behind a NAT. The FreeBSD server is also behind a NAT.

Note, with the complete set of patches applied, Windows 7 clients can connect from behind NAT utilizing its built-in VPN software, so there is no need to switch to a commercial one. These patches resolve also another issue with all sorts of clients, namely, finally many clients may concurrently connect from behind the same NAT to the VPN server. This was impossible without the kernel patches, because the standard ipsec key management in the kernel did not honour remote port numbers and became confused by more than one connections from the same remote IP.
 
rolfheinrich said:
Are you referring to the mere howto (posts #1-3 only) of this thread, or did you apply the complete set of ipsec-tool and kernel patches revealed in post #82?

I'm referring to the Howto and the first two patches, so patch-zz-local-0.diff and patch-zz-local-1.diff. Those other patches weren't available yet when I configured it in the beginning of July. The reason I replied that I got it working with shrewsoft was because of this in the beginning of the Howto:

rolfheinrich said:
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 incoming calls at port 1701.

Might want to change that if it does work now with the additional patches :)

Good to see that patches have been created so it works natively as well. Any chance these patches will get added to the ports / included in racoon?

Thanks a lot for the Howto BTW!
 
Works with PF and DDNS too, no shell script needed

Supplementing Rolf's excellent guide :stud -Thank You again Rolf! -, there's one other article that details how to make this work if you use PF instead of IPFW to filter out the curious ;). Link: http://wiki.stocksy.co.uk/wiki/L2TP_VPN_in_FreeBSD

Based on these two astounding articles, I'd like to share my experience setting up my SOHO FreeBSD router/ firewall and make it work with PF, No-IP and dynamic public IP without any shell script.

First and foremost my FreeBSD router/ firewall box (this is important, my proven working configuration may not work with your box's hardware setup):
  • Runs FreeBSD 9.1-RELEASE-p7 #0, PF and NO-IP versions from the latest ports collection
  • Three NICs: 1st runs PPPoE with the ISP (Dynamic IP), 2nd setup for MTU 9000 private subnet (i.e. a.a.a.0/24), 3rd setup for MTU 1500 private subnet (i.e. b.b.b.0/24)
  • Routing/ forwarding is done by FreeBSD (net.inet.ip.forwarding: 1), NAT is done by PF
  • DHCP is done by dhcpd toward both private subnets, version from the latest ports collection

Steps:
  1. If you don't already have it; register with No-IP, choose a free public domain hostname (i.e. ironman.no-ip.org) and install No-IP daemon from the ports collection
  2. I followed Rolf's Part I through II guide (i.e. steps 1 through 3.3) but removed the following section in step 3.1 (this will make racoon to listen to all network interfaces):
    Code:
    listen
    {
            isakmp           192.168.0.1 [500];
            isakmp_natt      192.168.0.1 [4500];
            strict_address;
    }
  3. Also in Rolf's step 3.2 in 'l2tp_server:' section, I modified the following entry:
    Code:
    # Define dynamic IP address pool.
            set ippool add pool_l2tp a.a.a.ax a.a.a.ay
    where a.a.a.ax through a.a.a.ay (in my case) is the range within one of my private subnets that will be assigned to my VPN clients BUT ones that I will not assign to any of my DHCP clients nor my static private IP address servers.

    And for the following entry I modified to this:
    Code:
    # Specify IP address pool for dynamic assigment.
            set ipcp ranges a.a.a.az/24 ippool pool_l2tp
            set ipcp dns c.c.c.c
            set ipcp dns d.d.d.d

    Where a.a.a.az will be the IP address of my router/ firewall/ VPN server box end for tunnels established with VPN clients. It's a unique IP address within one of my private subnets range that's not gonna be assigned to my VPN client nor my DHCP client nor my static IP address servers. c.c.c.c and d.d.d.d are my ISP's DNS servers.

    Lastly the following entry:
    Code:
    # Configure L2TP
            set l2tp self ironman.no-ip.org

    Where ironman.no-ip.org is the free public domain hostname I got from No-IP i.e. the network interface that's running PPPoE with my ISP and getting dynamic public IP address.

Once done, every time my ISP assign a new dynamic public IP address racoon will automatically refresh the IP address it is listening to and racoon.log will show the following:
Code:
2013-09-30 20:42:41: INFO: mac:mac::mac:mac:mac:mac[500] used as isakmp port (fd=21)
2013-09-30 20:42:41: INFO: mac:mac::mac:mac:mac:mac[4500] used as isakmp port (fd=22)
2013-09-30 20:42:44: INFO: e.e.e.e[500] used for NAT-T
2013-09-30 20:42:44: INFO: e.e.e.e[500] used as isakmp port (fd=21)
2013-09-30 20:42:44: INFO: e.e.e.e[4500] used for NAT-T
2013-09-30 20:42:44: INFO: e.e.e.e[4500] used as isakmp port (fd=22)

Where e.e.e.e is the newly assigned dynamic public IP address from my ISP.

My pf.conf:
Code:
# MACROS
wan="tun0"

lan1="em0"
lan2="em1"

localsubnet1=$lan1:network
localsubnet2=$lan2:network

# PACKET NORMALIZATION
scrub in all

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

# REDIRECTION

# PACKET FILTERING
antispoof log quick for ($wan)
block in log on $wan from any to any
pass in log on $lan1 from $localsubnet1 to any keep state
pass in log on $lan2 from $localsubnet2 to any keep state
pass out log on $wan from ($wan) to any keep state
pass in log on $wan proto udp from any to ($wan) port {1701, 500, 4500} keep state
pass in log on $wan proto esp from any to ($wan) keep state
pass quick log on ng0 all
pass quick log on ng1 all
pass quick log on ng2 all
 
ilemur said:
Can somebody please post a short guide on steps necessary to patch for NAT-T under 9.2-RELEASE?

I am still on 9.1-RELEASE, and therefore I cannot tell whether the canonical procedure works on 9.2-RELEASE.

Step 0: Backup
Before patching the kernel make a backup of the affected sources - here I show the usage of clone(1)() (sysutils/clone) for backing-up and rolling-back:
# clone /usr/src/sys/netinet ~/netinet.back
# clone /usr/src/sys/netipsec ~/netipsec.back

Step 1: Patch and re-build the kernel
# fetch -o ~/ipsec-patches.diff "http://forums.freebsd.org/attachment.php?attachmentid=1925&d=1375044887"
# openssl dgst -sha256 ~/ipsec-patches.diff
Code:
SHA256(/root/ipsec-patches.diff)= 55a39ef4289de4276985553493bdb57ef80302afa876e9d7f4f41ecdefd970f5
# cd /usr/src
# patch -p1 < ~/ipsec-patches.diff

If the patch command succeeded, then re-build the kernel, and after this continue with step 3 below.

Step 2: Rolling-back (only if something went wrong)
If the patch command showed errors (not every warning is an error), then roll-back the sources, adapt the ~/ipsec-patches.diff hinted by the error messages, and then try it with the adapted .diff again. For rolling-back, you can use:
# clone -dy ~/netinet.back /usr/src/sys/netinet
# clone -dy ~/netipsec.back /usr/src/sys/netipsec

Step 3: Place the ipsec-tools-patches into secrurity/ipsec-tools and rebuild the ipsec-tools
# fetch -o ~/ipsec-tools-patches.zip "http://forums.freebsd.org/attachment.php?attachmentid=1926&d=1375045090"
# unzip -jd /usr/ports/security/ipsec-tools/files ~/ipsec-tools-patches.zip
# openssl dgst -sha256 ~/ipsec-tools-patches.zip
Code:
SHA256(/root/ipsec-tools-patches.zip)= 3045756e7999d5e6895af9559bcec022ef0a1c0a3c5664887257e2646f4619fd
# cd /usr/ports/security/ipsec-tools
# make deinstall
# make install clean

If you want to connect Windows clients, then you need to set the following sysctl to 1:
Code:
net.inet.esp.esp_ignore_natt_cksum=1

In addition, if both the server and the client are behind NAT, you need to hack the Windows 7 registry -- MS KB article 947234.

Furthermore, for some reasons racoon fails to completely tear down the security associations when a doubly NATTed Windows client disconnects. In this case install the tear down script that I already described here.

Some Android clients seem to have yet another problem with L2TP/IPsec.
 
rolfheinrich said:
I am still on 9.1-RELEASE, and therefore I cannot tell whether the canonical procedure works on 9.2-RELEASE.

You provide great support. Thanks! Really appreciating it.
Well on 9.2-RELEASE everything goes smoothly - now testing ipsec-tools part
Code:
 patch -p1 < ~/ipsec-patches.diff
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -rup src/sys/netinet/tcp_input.c sru/sys/netinet/tcp_input.c
|--- src/sys/netinet/tcp_input.c        2012-11-04 14:26:51.000000000 -0200
|+++ sru/sys/netinet/tcp_input.c        2012-11-28 18:53:56.000000000 -0200
--------------------------
Patching file sys/netinet/tcp_input.c using Plan A...
Hunk #1 succeeded at 700 (offset -5 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -rup src/sys/netipsec/esp_var.h sru/sys/netipsec/esp_var.h
|--- src/sys/netipsec/esp_var.h 2012-11-04 14:26:53.000000000 -0200
|+++ sru/sys/netipsec/esp_var.h 2012-11-28 18:53:56.000000000 -0200
--------------------------
Patching file sys/netipsec/esp_var.h using Plan A...
Hunk #1 succeeded at 79 with fuzz 1 (offset 2 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -rup src/sys/netipsec/ipsec_input.c sru/sys/netipsec/ipsec_input.c
|--- src/sys/netipsec/ipsec_input.c     2012-11-04 14:26:53.000000000 -0200
|+++ sru/sys/netipsec/ipsec_input.c     2012-11-29 20:45:42.000000000 -0200
--------------------------
Patching file sys/netipsec/ipsec_input.c using Plan A...
Hunk #1 succeeded at 76.
Hunk #2 succeeded at 352 (offset -2 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -rup src/sys/netipsec/key.c sru/sys/netipsec/key.c
|--- src/sys/netipsec/key.c     2012-11-04 14:26:53.000000000 -0200
|+++ sru/sys/netipsec/key.c     2012-11-29 18:40:34.000000000 -0200
--------------------------
Patching file sys/netipsec/key.c using Plan A...
Hunk #1 succeeded at 460.
Hunk #2 succeeded at 1315.
Hunk #3 succeeded at 2964.
Hunk #4 succeeded at 3090.
Hunk #5 succeeded at 3513.
Hunk #6 succeeded at 3806.
Hunk #7 succeeded at 4128.
Hunk #8 succeeded at 4727.
Hunk #9 succeeded at 4818.
Hunk #10 succeeded at 5166.
Hunk #11 succeeded at 5268.
Hunk #12 succeeded at 5484.
Hunk #13 succeeded at 5549.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -rup src/sys/netipsec/keydb.h sru/sys/netipsec/keydb.h
|--- src/sys/netipsec/keydb.h   2012-11-04 14:26:53.000000000 -0200
|+++ sru/sys/netipsec/keydb.h   2012-11-28 18:53:56.000000000 -0200
--------------------------
Patching file sys/netipsec/keydb.h using Plan A...
Hunk #1 succeeded at 163.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -rup src/sys/netipsec/xform_esp.c sru/sys/netipsec/xform_esp.c
|--- src/sys/netipsec/xform_esp.c       2012-11-04 14:26:53.000000000 -0200
|+++ sru/sys/netipsec/xform_esp.c       2012-11-28 18:53:56.000000000 -0200
--------------------------
Patching file sys/netipsec/xform_esp.c using Plan A...
Hunk #1 succeeded at 78.
done
 
Well all ipsec-tools patches also went without a hitch.
So the patches are applicable to the FreeBSD 9.2 system. Although my networking part is completely broken. Clients cannot connect to the internet or access local resources. Ping pass but from what i can tell by watching tcpdump output there is something misunderstnading between NAT-T and pf NAT.
PPTP connection using same config works flawlessly.

on ng0 is ee packets coming to server - but none to the vpn client (172.16.5.200)
Code:
172.16.5.200.35506 > some1.my.servers.microsoft-ds: Flags [S], cksum 0x28a0 (correct), seq 2667378455, win 13600, options [mss 1332,sackOK,TS val 2385198 ecr 0,nop,wscale 5], length 0
11:36:29.698760 IP (tos 0x0, ttl 64, id 37434, offset 0, flags [DF], proto TCP (6), length 60)

and on the external interface i see something like this

Code:
tcpdump: listening on dc0, link-type EN10MB (Ethernet), capture size 65535 bytes
    broadband.myserver.com.60782 > 89.222.207.137.http: Flags [S], cksum 0x3ebf (correct), seq 319505738, win 13600, options [mss 1332,sackOK,TS val 2490227 ecr 0,nop,wscale 5], length 0
    broadband.myserver.com.60782 > 89.222.207.137.http: Flags [S], cksum 0x3e5b (correct), seq 319505738, win 13600, options [mss 1332,sackOK,TS val 2490327 ecr 0,nop,wscale 5], length 0
    89.222.207.137.http > broadband.myserver.com.60782: Flags [S.], cksum 0x8817 (correct), seq 2695984557, ack 319505739, win 14480, options [mss 1460,sackOK,TS val 3367818120 ecr 2490227,nop,wscale 7], length 0
    172.16.5.200.40850 > 89.222.207.137.http: Flags [R.], cksum 0x5bb6 (correct), seq 334730228, ack 3371067425, win 0, length 0
    broadband.myserver.com > 89.222.207.137: ICMP host broadband.myserver.com unreachable, length 68
    89.222.207.137.http > broadband.myserver.com.60782: Flags [S.], cksum 0x1f68 (incorrect -> 0x3886), seq 2695984557, ack 334730228, win 14480, options [mss 1460,sackOK,TS val 3367818120 ecr 2490227,nop,wscale 7], length 0
    broadband.myserver.com.54139 > 89.222.207.137.http: Flags [S], cksum 0xe9a0 (correct), seq 4048142987, win 13600, options [mss 1332,sackOK,TS val 2490484 ecr 0,nop,wscale 5], length 0
    89.222.207.137.http > broadband.myserver.com.54139: Flags [S.], cksum 0xbf25 (correct), seq 1629502203, ack 4048142988, win 14480, options [mss 1460,sackOK,TS val 3367819690 ecr 2489081,nop,wscale 7], length 0
    broadband.myserver.com.59401 > 89.222.207.137.http: Flags [S], cksum 0x6424 (correct), seq 1080648153, win 13600, options [mss 1332,sackOK,TS val 2490508 ecr 0,nop,wscale 5], length 0
    89.222.207.137.http > broadband.myserver.com.59401: Flags [S.], cksum 0x9ed2 (correct), seq 1059944766, ack 1080648154, win 14480, options [mss 1460,sackOK,TS val 3367819929 ecr 2489106,nop,wscale 7], length 0
    broadband.myserver.com.60782 > 89.222.207.137.http: Flags [S], cksum 0x5842 (correct), seq 319505738, win 13600, options [mss 1332,sackOK,TS val 2490527 ecr 0,nop,wscale 5], length 0
    89.222.207.137.http > broadband.myserver.com.60782: Flags [S.], cksum 0xb43d (correct), seq 2742697419, ack 319505739, win 14480, options [mss 1460,sackOK,TS val 3367820111 ecr 2490527,nop,wscale 7], length 0
    172.16.5.200.40850 > 89.222.207.137.http: Flags [R.], cksum 0x90cf (correct), seq 0, ack 46712863, win 0, length 0
    broadband.myserver.com > 89.222.207.137: ICMP host broadband.myserver.com unreachable, length 68
    89.222.207.137.http > broadband.myserver.com.60782: Flags [S.], cksum 0x4b8e (incorrect -> 0x64ac), seq 2742697419, ack 334730228, win 14480, options [mss 1460,sackOK,TS val 3367820111 ecr 2490527,nop,wscale 7], length 0
    broadband.myserver.com.60782 > 89.222.207.137.http: Flags [S], cksum 0x56b1 (correct), seq 319505738, win 13600, options [mss 1332,sackOK,TS val 2490928 ecr 0,nop,wscale 5], length 0

So i'm not sure they work together. I have posted the problem in the Networking section of the forum.

UPDATE 10|11|2013

Well switching to IPFW _ IPFW NAT as stated on the first page worke flawlessly. So i have to confirem some BUG issue between NAT_T and PF NAT
 

Attachments

  • racoon.conf.txt
    1 KB · Views: 618
  • racoon.log.zip
    9.2 KB · Views: 386
MPD5 problem with FreeBSD 9.2-RELEASE-p1

Please read the update in the next message, the following information is outdated.

Finally, I upgraded from 9.1 RELEASE-p7 to 9.2-RELEASE-p1, using freebsd-update.

After this, my server behaved strange after a L2TP/IPsec-VPN connection had been established. The VPN client can access resources on the server, but not in the LAN and WAN, as it could on 9.1. Even more bugging is, that LAN clients cannot access the internet anymore, once a VPN connection was made, and the problem persists even after the VPN was disconnected, and persists after the net/mpd5, racoon were killed, and any dangling SA and SPD had been flushed. netstat -nr and sockstat -4 show nothing strange.

First, I thought that this could be a problem of the ipsec patches that I applied to my custom kernel, and I did some tests with PPTP by mpd5 using a pristine 9.2 GENERIC one. The same happened with that. Once an external client established a PPTP-VPN connection, all the internal LAN clients were effectively clipped from he internet.

Finally, I switched from net/mpd5 to net/sl2tps, and this resolved the problem for L2TP/IPsec connections from Mac OS X 10.8 and iOS 7 clients. Configuration of sl2tps was straightforward. I simply made a copy of the sample config.xml file, and I edited the pertinent settings. sl2tps did not come with a rc startup script, therefore, I quickly created one and put it to /usr/local/etc/rc.d/sl2tps:
Code:
#!/bin/sh

# FreeBSD rc-script for auto-starting/stopping the static L2TP server sl2tps in daemon mode
#
# PROVIDE: sl2tps
# REQUIRE: racoon
# KEYWORD: shutdown
#
# Add the following lines to /etc/rc.conf to enable the static L2TP server:
#
#    sl2tps_enable="YES"
#
# optional:
#    sl2tps_flags="-f /custom/path/to/config.xml"
#    sl2tps_user="non_root"
#    sl2tps_group="non_wheel"

. /etc/rc.subr

name=sl2tps
rcvar=sl2tps_enable

load_rc_config $name

: ${sl2tps_enable="NO"}
: ${sl2tps_pidfile="/var/run/sl2tps.pid"}
: ${sl2tps_flags=""}
: ${sl2tps_user="root"}
: ${sl2tps_group="wheel"}

command="/usr/local/bin/sl2tps"
command_args=""

run_rc_command "$1"
 
Update:

net/mpd5 is working for me again. Instead of
Code:
gateway_enable="YES"
in /etc/rc.conf, I had directly adjusted the related sysctl settings
Code:
net.inet.ip.forwarding=1
and
Code:
net.inet6.ip.forwarding=1
in /etc/sysctl.conf. On the freebsd-net mailing list I was informed that this shortcut doesn't work reliable anymore in FreeBSD 9.2. I removed the respective sysctl assignments and set
Code:
gateway_enable="YES"
and the VPN server works as before.

IMHO, net/mpd5 is much more versatile than net/sl2tps, and I continue using mpd5.
 
The gateway_enable setting has always been the IPv4 forwarding option and does nothing for IPv6. For IPv6 you have to use ipv6_gateway_enable.
 
kpa said:
The gateway_enable setting has always been the IPv4 forwarding option and does nothing for IPv6. For IPv6 you have to use ipv6_gateway_enable.

Yes, I forgot to mention it. I don't use IPv6 on my setup, and therefore, I left it disabled. Those, who need IPv6 need to set
Code:
ipv6_gateway_enable="YES"
of course.

The full story on what happened has been revealed on the freebsd-net mailing on end of October 2013: MPD PPTP seting 0 on net.inet.ip.forwarding.

It seems to be a collateral damage of changes to the devd(8)() system. As has been suggested, I disabled devd on my server by setting
Code:
devd_enable="NO"
in /etc/rc.conf. My understanding is that devd is of limited use for servers anyway, and perhaps of some use on desktops.
 
Back
Top