Date: Sat, 11 Dec 1999 00:05:30 +0200 (EET) From: Pekka Savola <pekkas@netcore.fi> To: freebsd-net@freebsd.org Subject: FreeBSD ipsec VPNs / pipsecd problems. Message-ID: <Pine.LNX.4.10.9912102333560.11535-100000@netcore.fi>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.10.9912102333560.11535-100000>