From owner-freebsd-net Fri Dec 10 14: 5:36 1999 Delivered-To: freebsd-net@freebsd.org Received: from netcore.fi (netcore.fi [193.94.160.1]) by hub.freebsd.org (Postfix) with ESMTP id 3F22C14A10 for ; Fri, 10 Dec 1999 14:05:32 -0800 (PST) (envelope-from pekkas@netcore.fi) Received: from localhost (pekkas@localhost) by netcore.fi (8.9.3/8.9.3) with ESMTP id AAA11693 for ; Sat, 11 Dec 1999 00:05:30 +0200 Date: Sat, 11 Dec 1999 00:05:30 +0200 (EET) From: Pekka Savola To: freebsd-net@freebsd.org Subject: FreeBSD ipsec VPNs / pipsecd problems. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello all, This might be related to freebsd-ports too. First, I'd like to know about experiences using FreeBSD for IPSEC VPN's. There seems to be two current alternatives: Kame and pipsecd. A port from OpenBSD seems to be outdated. Kame is a big package, but doesn't probably fit well in a dynamic environment, where patches and sourcecodes are updated daily, make world done now and then, etc. In the other hand, pipsecd looked pretty tiny and neat. Too bad its documentation is still next to nonexistant. I decided to try this to create a VPN between my Linux box (FreeS/WAN 1.1) and this (FreeBSD 3.3-RELEASE). This box had successfully been the other end of the VPN when it still ran Linux. I got into problems using pipsecd. More of this below. Has anyone gotten pipsecd to work properly? Has anyone managed to interoperate it with other VPN implementations ? Are there any other VPN implementations to try? Second, I got loads of warnings when compiling the pipsecd port. These might relate to the non-operability of this.: ------ ===> Building for pipsecd-19991014 gcc -Wall -I/usr/local/include/openssl -I/usr/local/include -g -o pipsecd tunip.c -L/usr/local/lib -lcrypto -lRSAglue -lrsaref -DFILE_PREFIX=\"/usr/local\" tunip.c:367: warning: initialization from incompatible pointer type tunip.c:367: warning: initialization from incompatible pointer type tunip.c:368: warning: initialization from incompatible pointer type tunip.c:372: warning: initialization from incompatible pointer type tunip.c:372: warning: initialization from incompatible pointer type tunip.c:373: warning: initialization from incompatible pointer type tunip.c:377: warning: initialization from incompatible pointer type tunip.c:377: warning: initialization from incompatible pointer type tunip.c:378: warning: initialization from incompatible pointer type tunip.c: In function `parse_secret': tunip.c:932: warning: int format, pointer arg (arg 3) tunip.c:944: warning: int format, pointer arg (arg 3) tunip.c: In function `config_read': tunip.c:980: warning: passing arg 1 of `strsep' from incompatible pointer type tunip.c:984: warning: passing arg 1 of `strsep' from incompatible pointer type tunip.c:1024: warning: passing arg 1 of `strsep' from incompatible pointer type tunip.c:1142: warning: passing arg 1 of `strsep' from incompatible pointer type tunip.c: In function `my_des_cbc_encrypt': tunip.c:2009: warning: passing arg 5 of `des_cbc_encrypt' from incompatible pointer type tunip.c: In function `my_des_cbc_decrypt': tunip.c:2021: warning: passing arg 5 of `des_cbc_encrypt' from incompatible pointer type tunip.c: In function `my_des_setkey': tunip.c:2032: warning: passing arg 1 of `des_set_key' from incompatible pointer type tunip.c: In function `my_des3_cbc_encrypt': tunip.c:2041: warning: passing arg 7 of `des_ede3_cbc_encrypt' from incompatible pointer type tunip.c: In function `my_des3_cbc_decrypt': tunip.c:2049: warning: passing arg 7 of `des_ede3_cbc_encrypt' from incompatible pointer type tunip.c: In function `my_des3_setkey': tunip.c:2057: warning: passing arg 1 of `des_set_key' from incompatible pointer type tunip.c:2059: warning: passing arg 1 of `des_set_key' from incompatible pointer type tunip.c:2061: warning: passing arg 1 of `des_set_key' from incompatible pointer type ------ I remember seeing similar errors (des_ede3_cbc_encrypt) when some Linux application was designed for SSLeay but compiled against OpenSSL. Has anyone else gotten into troubles like this? RSAref and OpenSSL 0.94 are installed as they should be. The actual non-operativity occurs as follows: I have disabled ESP etc. in the configuration to make this as simple as possible: sa ipah spi=0x1000 auth=hmac-md5-96 akey=d0-------- key ---------------b8 sa ipah spi=0x1000 auth=hmac-md5-96 akey=d0-------- key ---------------b8 dest=bbb.bbb.bbb.bbb if /dev/tun0 local_spi=0x1000 remote_spi=0x1000 Configured the interface and the route: ifconfig tun0 10.0.0.1 10.0.0.2 mtu 1440 route add -host 10.0.0.2 10.0.0.1 -interface As a result, when I ping the other end's virtual address, I can see with tcpdump that packets are sent and are received: [pinger] 23:56:39.772813 aaa.aaa.aaa.aaa > bbb.bbb.bbb.bbb : ip-proto-51 108 [pingee] 23:58:20.970713 aaa.aaa.aaa.aaa > bbb.bbb.bbb.bbb : ip-proto-51 108 [dates are off by purpose] The same occurs if the situation is reversed. However, it seems like neither host can open each other's AH'ed packets. Could this be caused by wrong SPI's? Are there any good diagnostic utilities to see whether ipsec programs actually got those but discarded them because of a wrong key, wrong encryption, or such ? HTH, Pekka Savola Btw, I just started using FreeBSD yesterday, so be gentle :) Also, I'm not subscribing to this list, so if anything comes up, please CC it to me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message