From owner-freebsd-net@freebsd.org Sat May 12 23:37:24 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 683D3FD7805 for ; Sat, 12 May 2018 23:37:24 +0000 (UTC) (envelope-from ascherrer@gmail.com) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D3C816A12E for ; Sat, 12 May 2018 23:37:23 +0000 (UTC) (envelope-from ascherrer@gmail.com) Received: by mail-wr0-x232.google.com with SMTP id y15-v6so8620132wrg.11 for ; Sat, 12 May 2018 16:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=iAT5gCussHjKTJurEmV8bqjYPaz151nTM3J7Ghurr/c=; b=tGxymSjkmQGFVqQp4gYZX+NK91dRV+1K6UUDQUBqkiE90pzzeJmm/2uNEkVYYxFjXx HJc6HDCg2ocKrbg/DH8ozlf/oMWQHdGW4hmTygmyHtUNFu+XuED0wQhVcHNZrLV4wWNH i8yXeP2mwyYhlIAEila+GNGeJ4JP7R19drUaRIu6id/wKTqmopcUrxlBEc27x2XsGLv0 /0Sp5saAZ4Vpj77Hd9c5nDAIs1ViiiB2IheyyhIp53d/DcEfxzEuc4BJKQOqQ/Wu6LwV IuThrZ9RGRCHdnP6c02KAMO9ssC89fvt1VHTSAzSPHbSUf6pN97J5d+Y5wR2K4gSGjhj m1ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=iAT5gCussHjKTJurEmV8bqjYPaz151nTM3J7Ghurr/c=; b=rVB2Ne9BKQz4G8pV3q1P60eQbE7gW/+E3sDz95eM4y+SQkpBXT6cCIIiRnx55JNUYw /irVOiFYeN5v6RP3Iu8H5bXARkNRljt2oghCiok82g6POuJAidQVjhrMFWZe2nnsuhAL jN24q+zt6Vsk/h6kNoMu4tqq3tz2AXadWsMa2EUzN6AJKS06KVcDLwle8rjkA6FJJlsu MzzEg+TXTfl2AjO+lsdsZ78t/ZlnIJxODD/zrN82sgm7fVd2kmZyuHsrsTHQuHGrJ7Ew WY2tG7GHfXuVu/sxwoXHzGiAIGKokg+t0lhUpD5ncO1MlQBPYWlay8w6aDyDMsidg7rB UdnQ== X-Gm-Message-State: ALKqPwcTyUziXRRjGTMd75bByck9igvyjcO449boDrLI/wCGJVkRczas 0cIEh9XvB7ML7n37IZSRKgM0fwiz X-Google-Smtp-Source: AB8JxZpnLF17H07ubYuzcMEV1u+91bItm3MAmDbdbQ+f+ubrMzQ56mUOj5pbggLzTqQ7JTEfj+dGtg== X-Received: by 2002:adf:aeea:: with SMTP id y97-v6mr3157297wrc.32.1526168242441; Sat, 12 May 2018 16:37:22 -0700 (PDT) Received: from juntos.woohoo.ch ([2a02:168:681c:460:21df:30a9:eed8:2475]) by smtp.gmail.com with ESMTPSA id p189-v6sm3135531wmg.18.2018.05.12.16.37.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 May 2018 16:37:21 -0700 (PDT) To: freebsd-net@freebsd.org From: Andreas Scherrer Subject: Site-to-site IPSec VPN using if_ipsec and racoon Message-ID: <951ef6f6-95d8-8832-1e7a-59fc90434029@gmail.com> Date: Sun, 13 May 2018 01:37:21 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2018 23:37:24 -0000 Hi I am trying to configure a site to site VPN using the (new?) if_ipsec interfaces [1]. One endpoint is FreeBSD 11.1-RELEASE whereas the other will be a RPi (Raspbian 9.4 stretch running libreswan). The public IPs involved are all IPv6 and the goal is to tunnel IPv4 traffic. Currently I am struggling with the FreeBSD side (which is using racoon if that is relevant). The documentation [1] states: "When the if_ipsec interface is configured, it automatically creates special security policies. These policies can be used to acquire security associations from the IKE daemon, which are needed for establishing an IPsec tunnel." But it does not say HOW to do that. My interpretation of [2]'s statement: "If no security association is found, the packet is put on hold and the IKE daemon is asked to negotiate an appropriate one." is that it should somehow be automagic. But in my current configuration, that does not happen. I never see FreeBSD initiate any IKE traffic (500/udp) and 'setkey -D' always reports "No SAD entries.". I have the 'ipsec0' interface configured and I do see the SPD entry with 'setkey -D -P [-t]': ----- # setkey -D -P -t 0.0.0.0/0[any] 0.0.0.0/0[any] any in ipsec esp/tunnel/-/unique:100 spid=75 seq=3 pid=10410 scope=ifnet ifname=ipsec0 refcnt=1 ::/0[any] ::/0[any] any in ipsec esp/tunnel/-/unique:100 spid=77 seq=2 pid=10410 scope=ifnet ifname=ipsec0 refcnt=1 0.0.0.0/0[any] 0.0.0.0/0[any] any out ipsec esp/tunnel/-/unique:100 spid=76 seq=1 pid=10410 scope=ifnet ifname=ipsec0 refcnt=1 ::/0[any] ::/0[any] any out ipsec esp/tunnel/-/unique:100 spid=78 seq=0 pid=10410 scope=ifnet ifname=ipsec0 refcnt=1 ----- And traffic to my test destination (192.168.112.1) is routed to 'ipsec0': ----- # route -n show 192.168.112.1 route to: 192.168.112.1 destination: 192.168.112.0 mask: 255.255.255.0 fib: 0 interface: ipsec0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1400 1 0 ----- By applying some "reverse logic" to another statement in [2]: "When a matching policy is found, the kernel will look for a corresponding security association" I deduct that maybe for some reason my traffic does not match the existing policy. But I do not see (or understand) why? Any traffic through 'ipsec0' should match that policy, no? I am under the impression that this is one of the basic ideas of having 'ipsec0' in the first place ("it automatically creates special security policies")? The example on [1] uses 'setkey -c' to manually configure the SA which is something I do not want to (and cannot) do. Can anybody point me in the right direction (be it more documentation or a working config example)? That would be awesome. Best regards andreas Ps.: I have tried the "old" approach which I know better using 'gif' interfaces. With that I have managed to get racoon negotiate SAs for the same tunnel (i.e. with libreswan on the RPi). Unfortunately I cannot wrap my head around the routing with that approach (no 'gif' on Raspbian). And the documentation also mentions this as a limitation of 'gif' [3]: "you cannot usually use gif to talk with IPsec devices that use IPsec tunnel mode" [1] https://www.freebsd.org/cgi/man.cgi?query=if_ipsec [2] https://vincent.bernat.im/en/blog/2017-route-based-vpn [3] https://www.freebsd.org/cgi/man.cgi?query=gif -- Stell dir vor es geht und keiner kriegt's hin.