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

Yes, either remove it, or set the value to 0, the default behaviour of Windows, see https://support.microsoft.com/en-us/kb/926179.

Done.

Clearly you are on IPv6, and for sure IPv6 UDP decapsulation won't work by no means on your server, for this to know, we need only to read the initial section of your last connection log:

The main problem for me that I didn't use IPv6

In addition, something is occupying already the IPv4 port 500 and/or 4500, and for this reason IPv4 has been disabled.

Sockstat output:
Code:
(pts/3)[root@server:/usr/local/etc]# sockstat | grep 500
root     charon     10816 11 udp4 6 *:500                 *:*
root     charon     10816 12 udp4 6 *:4500                *:*
root     ntpd       1500  3  dgram  -> /var/run/logpriv
root     ntpd       1500  20 udp4   *:123                 *:*
root     ntpd       1500  21 udp4   10.0.0.1:123          *:*
root     ntpd       1500  22 udp4   192.168.1.1:123       *:*
root     ntpd       1500  23 udp4   127.0.0.1:123         *:*
root     ntpd       1500  24 udp4   85.113.221.175:123    *:*
root     ntpd       1500  28 udp4   10.1.200.1:123        *:*
root     ntpd       1500  29 udp4   10.20.0.5:123         *:*
root     rtorrent   1470  13 tcp4   127.0.0.1:5000        *:*
root     mpd5       1331  16 tcp4   127.0.0.1:5005        *:*

Are you connected via DS-Lite, or do you have a real IPv6 address? If you can't disable NAT then you will be on a dead end here. FreeBSD is not able to do IPv6 UDP decapsulation.
Your options are getting rid of DS-Lite, by switching either to pure IPv6 without NAT or to IPv4 (with or without NAT).

Server ip: 85.113.221.175 (static via PPPoE)
My external ip: 2.93.190.121 (dynamic)
My internal ip: 192.168.42.145 (behind NAT (OpenWRT router))
I use standard Win7 network manager.

No IPv6.
 
Why don't these IPv4 addresses show up in the strongSwan connection log, but instead it shows some mangled IPv6 addresses? Does the OpenWRT router do some sort of 4to6 translation?
 
Why don't these IPv4 addresses show up in the strongSwan connection log, but instead it shows some mangled IPv6 addresses? Does the OpenWRT router do some sort of 4to6 translation?

Hi,

Sorry for long delay. Recently I returned to this issue. I did test on another test machine (FreeBSD 10.2). It works.
However, I have concluded that there is a problem on the server.
I tried to connect from another addresses, but always in logs I see this address:
::ffff

May be my kernel has wrong options?
 

Attachments

  • KERNEL.txt
    23.1 KB · Views: 578
Why don't these IPv4 addresses show up in the strongSwan connection log, but instead it shows some mangled IPv6 addresses? Does the OpenWRT router do some sort of 4to6 translation?

Hi,

I did some interesting tests. I compiled this kernel: FreeBSD server 10.2-RELEASE-p8 FreeBSD 10.2-RELEASE-p8 with patch:

http://blog.obsigna.net/downloads/IPsec-NATT-Win_v10.2.patch

Unfortunatly, it doesn't have effect, but with 10.1 kernel old patch for racoon works successfully. May be 10.2-p8 has some changes, so patch IPsec-NATT-Win_v10.2.patch doesn't work. Unfortunatly, I don't know.
 
I just finished a quite thorough test on my server running FreeBSD 10.2-RELEASE-p8 (GENERIC_IPsec). My GENERIC_IPsec kernel configuration file contains:
Code:
include GENERIC
ident    GENERIC_IPsec

# Options for IPsec
options    IPSEC
options    IPSEC_NAT_T
device    crypto
In addition before making the custom kernel, /usr/src/sys/netinet/udp_usrreq.c has been patched using http://blog.obsigna.net/downloads/IPsec-NATT-Win_v10.2.patch.

My Windows 7 client can connect successfully from behind a NAT and two Mac OS X clients and more one iOS client can connect concurrently from behind the same NAT to the same L2TP/IPsec server running net/mpd5+security/stongswan, see:

windows-7-png.2902


The third entry belongs to the Windows 7 client. Without said patch, Windows 7 cannot connect. In addition I verified, that at my FreeBSD server nothing of the old racoon patch sets were left and forgotten in my kernel sources. In order to verify this, I did:

cd
mkdir -p orig-src/sys

svn co http://svn0.us-east.freebsd.org/base/releng/10.2/sys/netinet orig-src/sys/netinet
svn co http://svn0.us-east.freebsd.org/base/releng/10.2/sys/netinet6 orig-src/sys/netinet6
svn co http://svn0.us-east.freebsd.org/base/releng/10.2/sys/netipsec orig-src/sys/netipsec

diff -rI '\$FreeBSD*' orig-src/sys/netinet /usr/src/sys/netinet
Code:
Only in orig-src/sys/netinet: .svn
diff -rI '\$FreeBSD*' orig-src/sys/netinet/udp_usrreq.c /usr/src/sys/netinet/udp_usrreq.c
1557,1563d1556
<     /*
<     * We cannot yet update the cksums so clear any
<     * h/w cksum flags as they are no longer valid.
<     */
<     if (m->m_pkthdr.csum_flags & CSUM_DATA_VALID)
<         m->m_pkthdr.csum_flags &= ~(CSUM_DATA_VALID|CSUM_PSEUDO_HDR);
<
Only in /usr/src/sys/netinet: udp_usrreq.c.orig
That one was expected, because the new patch deleted the indicated lines.

diff -rI '\$FreeBSD*' orig-src/sys/netinet6 /usr/src/sys/netinet6
Code:
Only in orig-src/sys/netinet6: .svn
diff -rI '\$FreeBSD*' orig-src/sys/netipsec /usr/src/sys/netipsec
Code:
Only in orig-src/sys/netipsec: .svn
Conclusion, my custom kernel FreeBSD 10.2-RELEASE-p8 (GENERIC_IPsec) was built with only one patch in place, and with a minimal set of configuration additions -- and, the best of all, it works.
 

Attachments

  • Windows 7.png
    Windows 7.png
    46.6 KB · Views: 2,311
Conclusion, my custom kernel FreeBSD 10.2-RELEASE-p8 (GENERIC_IPsec) was built with only one patch in place, and with a minimal set of configuration additions -- and, the best of all, it works.

My kernel basically is GENERIC,

Code:
(pts/7)[root@server:/usr/src/sys/netinet]# uname -ar
FreeBSD server 10.2-RELEASE-p8 FreeBSD 10.2-RELEASE-p8 #0 r293283M: Thu Jan  7 03:37:27 MSK 2016     root@server:/usr/obj/usr/src/sys/SERVER  i386

this is my custom part:

Code:
#CUSTOM KERNEL FOLLOWING...
options         NETGRAPH
options         NETGRAPH_PPP
options         NETGRAPH_PPTPGRE
options         NETGRAPH_ETHER
options         NETGRAPH_SOCKET
options         NETGRAPH_TEE
options         NETGRAPH_ASYNC
options         NETGRAPH_IFACE
options         NETGRAPH_MPPC_ENCRYPTION
options         NETGRAPH_MPPC_COMPRESSION
options         NETGRAPH_BPF
options         NETGRAPH_KSOCKET
options         NETGRAPH_TCPMSS
options         NETGRAPH_VJC
options         NETGRAPH_ONE2MANY
options         NETGRAPH_RFC1490
options         NETGRAPH_TTY
options         NETGRAPH_UI
options         LIBALIAS
options         MROUTING
options         NETGRAPH_PPPOE
options         NETGRAPH_HOLE
options         NETGRAPH_ECHO
options         NETGRAPH_L2TP

# By Executor
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=999
options IPFILTER
options IPFILTER_LOG
options IPDIVERT
options DUMMYNET
options DEVICE_POLLING
#options IPFIREWALL_FORWARD
options IPFIREWALL_NAT
options IPFIREWALL_DEFAULT_TO_ACCEPT

#colortag
options SC_NORM_ATTR="(FG_GREEN|BG_BLACK)"
options SC_NORM_REV_ATTR="(FG_YELLOW|BG_GREEN)"
options SC_KERNEL_CONS_REV_ATTR="(FG_BLACK|BG_RED)"
options SC_KERNEL_CONS_ATTR="(FG_RED|BG_BLACK)"

# For HTTP Server
maxusers 512

#

options HZ=1000

# PF support
device          pf
device          pflog
device          pfsync
options         ALTQ
options         ALTQ_CBQ
options         ALTQ_RED
options         ALTQ_RIO
options         ALTQ_HFSC
options         ALTQ_PRIQ
options         ALTQ_NOPCC
options         SHMMAXPGS=65536
options         SEMMNI=40
options         SEMMNS=240
options         SEMUME=40
options         SEMMNU=120


#options RADIX_MPATH
#options COMPAT_FREEBSD8 # Compatible with FreeBSD8

#22-08-2012 for ZFS
#options         KVA_PAGES=160

#03-10-2013
# IPSec
options         IPSEC
options         IPSEC_FILTERTUNNEL
options         IPSEC_NAT_T
options         IPSEC_DEBUG
device          crypto
device          enc

#19-11-2013
options         VFS_AIO
device          tap

#28-02-2014
options MAC_PORTACL

This is patched file:

Code:
(pts/7)[root@server:/usr/src/sys/netinet]# diff -c ./udp_usrreq.c ./udp_usrreq.c.orig
*** ./udp_usrreq.c      2016-01-07 03:09:34.000000000 +0300
--- ./udp_usrreq.c.orig 2016-01-07 02:47:59.000000000 +0300
***************
*** 1554,1559 ****
--- 1554,1566 ----
        ip->ip_len = htons(ntohs(ip->ip_len) - skip);
        ip->ip_p = IPPROTO_ESP;

+       /*
+        * We cannot yet update the cksums so clear any
+        * h/w cksum flags as they are no longer valid.
+        */
+       if (m->m_pkthdr.csum_flags & CSUM_DATA_VALID)
+               m->m_pkthdr.csum_flags &= ~(CSUM_DATA_VALID|CSUM_PSEUDO_HDR);
+
        (void) ipsec4_common_input(m, iphlen, ip->ip_p);
        return (NULL);                  /* NB: consumed, bypass processing. */
  }
(pts/7)[root@server:/usr/src/sys/netinet]#

This is log of strongswan:

http://pastebin.com/7ZpRV4zG

Finally, I get 809 error in Win7. All configs from http://blog.obsigna.net/?p=520
May be my other kernel options can do effect to ipsec?
 
On the Windows client try the both registry changes described in the following support document by Microsoft:

https://support.microsoft.com/en-us/kb/947234

The description is about Windows Vista, however, it should work for Windows 7 as well. Set both values, namely the one of HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent\AssumeUDPEncapsulationContextOnSendRule and the other one of HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\IPsecThroughNAT to 2.
 
On the Windows client try the both registry changes described in the following support document by Microsoft:
https://support.microsoft.com/en-us/kb/947234
The description is about Windows Vista, however, it should work for Windows 7 as well. Set both values, namely the one of HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent\AssumeUDPEncapsulationContextOnSendRule and the other one of HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\IPsecThroughNAT to 2.

Unfortunately, it has no effect. As I wrote earlier, if to do rollback to kernel version 10.1 with an old kernel patch NAT-T for Racoon, it works (racoon or strongswan are worked well).
Most likely the problem in my server configuration. For example, Strongswan can start only during boot server. If you do Strongswan restart, it will no longer be working with an error:
Code:
could not open IPv4 socket, IPv4 disabled
It's very strange. While, I don't know how to solve my issue. The only thing that comes to mind is my set of custom kernel options can be reason of problem, but I can't test it on live server.
 
I followed these instructions, not to a "tee" as I have 20+ years of experience with FreeBSD, and was able to get a L2TP VPN up and running within an hour. Connecting from iOS was a breeze.

I installed racoon and mpd5 via:
# pkg install racoon
# pkg install mpd5

When I brought the system up I learned quickly that the wildcard IP check is NOT (yet) build into the prebuild port of racoon.
The solution is was simple:
# cd /usr/ports/ipsec-tools
# make configure
(Select the Wildcard option!)
# make
# make reinstall

Thank you for documenting this!
 
Hi to all,
Thanks to obsigna (aka. rolfheinrich) for this howto! I learnd so much!!

I successfully set up the VPN-Server on an aws instance.
I can connect my iPhone to it but it has no access to the internet (the website runing on port 8000 is reachable). I cant figure out why.

The next problem I encounterd is to set up a FreeBSD VPN-Client. I found that: Thread l2tp-ipsec-client.41846 but it is not working for me (I'm a little confused because there is no option for the PSK).

Another question came up while working with ipsec-tools, is it still secure to use? Currently it has no maintainer and I heard it has some securety issues.

I am aware of stongSwan and openVPN and that they are much more easy to set up but I realy want to use "truly" open-source software (BSD, MIT, Apache and so forth).

I'm struggling with those problems for a very long time now and would be happy with any advise and help.

I'm using: FreeBSD 12.1-RELEASE-p5 GENERIC amd64
I istalled all applications with pkg.

The appendix consists of config files I used and the racoon log file.
 

Attachments

  • ipfw.conf
    1.7 KB · Views: 230
  • mpd.conf
    1.1 KB · Views: 265
  • racoon.conf
    1 KB · Views: 222
  • rc.conf
    681 bytes · Views: 235
  • racoon.log.txt
    2.6 KB · Views: 214
This is quite an old thread, and a lot of water has flowed down the river Rhine since I started it. To begin with, security/ipsec-tools came with a lot of flaws and there were a lot of obstacles to overcome for getting it to work. In addition for working with pre-12.0 systems it was necessary to patch the kernel. I dropped usage of racoon from said ipsec-tools in favor of security/strongswan already some years ago. The latter is well mainteaind and much easier to set up. In addition no kernel patching is necessary anymore with FreeBSD 12.1-RELEASE.

Some times ago I wrote a BLog post on my setup utilizing net/mpd5 together with strongSwan:
German language: https://obsigna.com/articles/1548367297.html
English translation: https://www.translatetheweb.com/?from=de&to=en&a=https://obsigna.com/articles/1548367297.html

In a more recent thread about L2TP/IPsec client configuration on this forums, I showed my setup:

For getting this to work on AWS-EC2 instances, I create always an alias IP on the xn0 interface. This is because the primary IP range (172.z.z.z) seems to be shared with other instances and would not be exactly available for the IP pool for VPN clients.

Bash:
...
### Network
hostname="example.com"
ifconfig_DEFAULT="SYNCDHCP -tso"
ifconfig_xn0_alias0="inet 10.x.x.x netmask 255.255.255.0"
gateway_enable="YES"
...

I just opened an L2TP/IPsec connection to one of my instances:
ifconfig
Code:
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
    options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
    inet6 ::1 prefixlen 128
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
    inet 127.0.0.1 netmask 0xff000000
    groups: lo
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
xn0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 9001
    options=403<RXCSUM,TXCSUM,LRO>
    ether 06:f3:e9:dd:ac:91
    inet6 fe80::4f3:e9ff:fedd:ac91%xn0 prefixlen 64 scopeid 0x2
    inet 172.z.z.z netmask 0xfffff000 broadcast 172.z.z.255
    inet 10.x.x.1 netmask 0xffffff00 broadcast 10.x.x.255
    media: Ethernet manual
    status: active
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1280
    inet 10.x.x.1 --> 10.x.x.161 netmask 0xffffffff
    inet6 fe80::f4ef:9a0c:283e:4fe8%ng0 prefixlen 64 scopeid 0x3
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

In addition I run local_unbound on said instances as a caching recursive resolver, and in mpd.conf the address of this resolver is informed. This improves very much the privacy of our installations:
 
Thanks for the quick response.

I am familiar with your work and a huge fan. Sadly strongSwan is no option for me because of the GNU GPL.

I created the IP alias on the interface and tried various combinations of mpd.conf with it but failed to succeed. Which options do I have to change to the newly created alias IP?
I read your "Netzwerkdienste DNS und DHCP" BLog again but could not tie it to the problem I'm having. Is the local_unbound necessary to set up the VPN-Server? If so do you have some example configurations for my use case?
 
Thanks for the quick response.

I am familiar with your work and a huge fan. Sadly strongSwan is no option for me because of the GNU GPL.

I created the IP alias on the interface and tried various combinations of mpd.conf with it but failed to succeed. Which options do I have to change to the newly created alias IP?
I read your "Netzwerkdienste DNS und DHCP" BLog again but could not tie it to the problem I'm having. Is the local_unbound necessary to set up the VPN-Server? If so do you have some example configurations for my use case?
I mentioned the DNS setup, because in case the VPN client can't access a nameserver it would not reach the internet.

I don't like the GPL too much either, however, sometimes among a bad and a worse choice, I may opt for the bad one. I am liberal enough to let others do their own choices. That said, L2TP/IPsec works in two defined separate stages, and you may want to troubleshoot each stage separately. Please let me suggest that you install security/strongswan for the troubleshooting sessions only. Once you got everything working with strongSwan you would deactivate it for changing the IPsec part of the VPN to racoon. The benefit is, that you know that MPD5 and L2TP is working and you may focus on resolving any left IPsec issues with racoon.

Here come the configuration files of a working installation on an AWS-EC2 instance.
 

Attachments

  • ipfw.conf
    1.5 KB · Views: 248
  • mpd.conf
    1.1 KB · Views: 277
  • ipsec.conf
    290 bytes · Views: 246
  • strongswan.conf
    226 bytes · Views: 253
  • unbound.conf
    722 bytes · Views: 226
Last edited:
When I try to make buildkernel KERNCONF=GENERIC_IPsec


I get error
Code:
/usr/src/sys/amd64/conf/GENERIC_IPsec: unknown option "IPSEC_NAT_T"
Any suggestion?
 
Those options have been removed a long time ago (you're following 10 year old instructions). You don't need to recompile the kernel for IPSec to work (it's already enabled by default in the GENERIC kernel).

 
Those options have been removed a long time ago (you're following 10 year old instructions). You don't need to recompile the kernel for IPSec to work (it's already enabled by default in the GENERIC kernel).

so do i need the patches also ????
I installed Freebsd 13 i am search for a tutorial installing a Vpn server L2tp like this thread no luck.
 
No.

You might want to start with something a little easier to configure (IPSec is a bit of a pain to configure correctly), OpenVPN or WireGuard are probably easier to start with.
well i dont like 3rd part tools in windows clients.
in centos there is a script and everythign is setup automatically.
but i prefer freebsd
 
IPSec requires a quite a bit of networking knowledge. Certainly possible to set up (I have an IPSec tunnel between my home network and my VPS), but a major hurdle if you don't know the difference between layer 2 and 3, or how IPSec works.
 
I started this thread as another user, at that time I was @rolfheinrich. Actually a lot of things changed. To begin with, FreeBSD fully supports IPsec NATT without rebuilding the kernel, also more than one client may connect to the same server from behind the same NAT. Almost all obstacles of these old day had been teared down, and with the advent of security/strongswan which is working extremely well on FreeBSD, it is even a snap to get IPsec working.

IMHO, the big advantage of L2TP/IPsec over other VPNs is that almost all end user OS come with L2TP/IPsec clients pre-installed which are easy to configure. This is already handy if you use your server for yourself only, but it is of paramount importance if you want to setup the service for others. With L2TP/IPsec it is usually done by informing the server address and the credentials to the users. I am even not sure that L2TP/IPsec is more complicated to setup, than OpenVPN nowadays, and even if it is the little more work on the server side, is payed back quickly, by not needing to do anything on multiple clients.

I documented the setup which I use on my BLog. Unfortunately, this article is in German language, however I am sure that people are able to grasp the essentials from the English translation by the Google Translator:
In German: https://obsigna.com/articles/1548367297.html
English Translation by the Google Translator: https://obsigna-com.translate.goog/articles/1548367297.html?_x_tr_sl=de&_x_tr_tl=en
 
You article is Great and as far i can tell its the only One on the Web.
When you try to find vpn server for bsd supporting l2tp you see everything like openvpn etc.
many congrats for your article again.
 
is it possible with your configuration in the article to have a vpn on a virtual machine with one network interface and public ip x.x.x.x ?
or i sould install one more interface with local ip?

Thanks anyway.
 
is it possible with your configuration in the article to have a vpn on a virtual machine with one network interface and public ip x.x.x.x ?
or i sould install one more interface with local ip?

Thanks anyway.
No need to install another network interface. You may want to use the alias facility of ifconfig(8) to assign another network address to the network interface. For example, this is what I have on a number of AWS-EC2 instances:

Code:
ifconfig_DEFAULT="SYNCDHCP -tso"
ifconfig_xn0_alias0="inet 10.0.0.XX netmask 255.255.255.0"

The benefit is, that I don’t need to care whether the instance always gets assigned the same local IP from the AWS hypervisor. Whith that in place we would do all the adjustments according to my Blog post against 10.0.0.XX as if it were a network provided by a second NIC.
 
Back
Top