Date: Thu, 29 Dec 2005 12:14:00 +0000 From: Brian Candler <B.Candler@pobox.com> To: Eric Masson <e-masson@kisoft-services.com> Cc: freebsd-net@freebsd.org, VANHULLEBUS Yvan <vanhu_bsd@zeninc.net> Subject: Re: IPSEC documentation Message-ID: <20051229121359.GA10949@uk.tiscali.com> In-Reply-To: <868xu5p2ze.fsf@srvbsdnanssv.interne.kisoft-services.com> References: <20051228143817.GA6898@uk.tiscali.com> <001401c60bc0$a3c87e90$1200a8c0@gsicomp.on.ca> <20051228153106.GA7041@uk.tiscali.com> <20051228164339.GB3875@zen.inc> <868xu5p2ze.fsf@srvbsdnanssv.interne.kisoft-services.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Dec 28, 2005 at 06:04:37PM +0100, Eric Masson wrote: > > Did someone tried such a setup ? > > I plan to do so. > > Just have to find ios images that support l2tp and ipsec for my 1601R > or 2611 and bigger flash modules (I've been given them two weeks ago, > hardware upgrade is the easy part, for software, hope cisco will > permit hobbyist licences one of these days) > > > is there a L2TPD daemon running on FreeBSD which could be used for > > that ? > > ports/net/sl2tps I was rather surprised that I just got IPSEC tunnel mode working between Windows XP and FreeBSD; and then afterwards I also got transport mode + L2TP working using the Windows client and sl2tps. Zounds! There is a bug (arguably) in the ipsec-tools port, in that all useful messages are logged at level 'daemon.info', but the default syslog.conf discards these messages. Once that's fixed, debugging suddenly becomes a whole lot easier :-) I've submitted a PR. sl2tps seems flaky: it dumped core once at startup, although the backtrace was nothing I could make use of (see below), as I don't know how to debug a threaded application. It also desperately lacks the ability to authenticate against a RADIUS server. Once up, I can happily ping through the L2TP tunnel and run short telnet sessions but I can't view large web pages, which looks like an MTU issue. >From the PPP negotiation it lloks like an MRRU of 1600 is offered and rejected, and 1400 negotiated instead, which ought to be OK: debug: [192.168.1.200:1701]: LCP: event UP in state STARTING info: [192.168.1.200:1701]: LCP: xmit Conf-Req #0: [ACFComp] [PFComp] [Magic 0x4ae82076] [Auth CHAP-MD5] [MP-MRRU 1600] [MP-ShortSq] [EID IP:0.0.0.0] debug: [192.168.1.200:1701]: LCP: STARTING -> REQ-SENT info: [192.168.1.200:1701]: LCP: recv Conf-Rej #0: [MP-MRRU 1600] [MP-ShortSq] [EID IP:0.0.0.0] debug: [192.168.1.200:1701]: LCP: event RCN in state REQ-SENT info: [192.168.1.200:1701]: LCP: xmit Conf-Req #1: [ACFComp] [PFComp] [Magic 0x4ae82076] [Auth CHAP-MD5] info: [192.168.1.200:1701]: LCP: recv Conf-Ack #1: [ACFComp] [PFComp] [Magic 0x4ae82076] [Auth CHAP-MD5] debug: [192.168.1.200:1701]: LCP: event RCA in state REQ-SENT debug: [192.168.1.200:1701]: LCP: REQ-SENT -> ACK-RCVD info: [192.168.1.200:1701]: LCP: recv Conf-Req #1: [MRU 1400] [Magic 0x685733f2] [PFComp] [ACFComp] [Callback] debug: [192.168.1.200:1701]: LCP: event RCR- in state ACK-RCVD info: [192.168.1.200:1701]: LCP: xmit Conf-Rej #1: [Callback] info: [192.168.1.200:1701]: LCP: recv Conf-Req #2: [MRU 1400] [Magic 0x685733f2] [PFComp] [ACFComp] debug: [192.168.1.200:1701]: LCP: event RCR+ in state ACK-RCVD info: [192.168.1.200:1701]: LCP: xmit Conf-Ack #2: [MRU 1400] [Magic 0x685733f2] [PFComp] [ACFComp] debug: [192.168.1.200:1701]: LCP: ACK-RCVD -> OPENED A tcpdump on the external interface of the FreeBSD box is a bit strange though: the client chooses an mss of 1360 (= 1400 - 40 which is IP+TCP header), but the webserver chooses an mss of 1380 which is too large: 12:06:51.773708 IP myhost.60084 > www.example.com.80: S 3030435125:3030435125(0) win 65535 <mss 1360,nop,nop,sackOK> 12:06:51.960445 IP www.example.com.80 > myhost.60084: S 4134768352:4134768352(0) ack 3030435126 win 65535 <mss 1380,nop,nop,sackOK> 12:06:51.961377 IP myhost.60084 > www.example.com.80: . ack 1 win 65535 12:06:51.961922 IP myhost.60084 > www.example.com.80: P 1:299(298) ack 1 win 65535 12:06:52.136869 IP www.example.com.80 > myhost.60084: . 1:1361(1360) ack 299 win 65535 12:06:52.136959 IP myhost > www.example.com: ICMP myhost unreachable - need to frag, length 36 12:06:52.138064 IP www.example.com.80 > myhost.60084: . 1361:2721(1360) ack 299 win 65535 12:06:52.138125 IP myhost > www.example.com: ICMP myhost unreachable - need to frag, length 36 12:06:52.139195 IP www.example.com.80 > myhost.60084: . 2721:4081(1360) ack 299 win 65535 12:06:52.139256 IP myhost > www.example.com: ICMP myhost unreachable - need to frag, length 36 As it happens this FreeBSD box is also acting as a NAT gateway using pf (myhost is on a private IP) and actually its external IP is also private - it sits behind a second NAT firewall. So maybe that's where the problem originates, although I really can't understand where the value of 1380 comes from. Regards, Brian. GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... Core was generated by `sl2tps'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libpdel.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpdel.so.0 Reading symbols from /usr/local/lib/libexpat.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libexpat.so.5 Reading symbols from /usr/lib/libssl.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libssl.so.4 Reading symbols from /lib/libcrypto.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypto.so.4 Reading symbols from /lib/libcrypt.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.3 Reading symbols from /usr/lib/libradius.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libradius.so.2 Reading symbols from /usr/lib/libnetgraph.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libnetgraph.so.2 Reading symbols from /usr/lib/libpthread.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libpthread.so.2 Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x2825b2b7 in pthread_testcancel () from /usr/lib/libpthread.so.2 [New Thread 0x8056600 (runnable)] [New Thread 0x8056200 (LWP 100098)] [New Thread 0x8056000 (runnable)] [New LWP 100100] (gdb) bt #0 0x2825b2b7 in pthread_testcancel () from /usr/lib/libpthread.so.2 #1 0x28253dac in pthread_mutexattr_init () from /usr/lib/libpthread.so.2 #2 0x00000000 in ?? () (gdb) quit
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051229121359.GA10949>