From owner-freebsd-security Sat Sep 30 22: 8: 7 2000 Delivered-To: freebsd-security@freebsd.org Received: from public.bta.net.cn (public.bta.net.cn [202.96.0.97]) by hub.freebsd.org (Postfix) with SMTP id 1E95B37B502 for ; Sat, 30 Sep 2000 22:08:04 -0700 (PDT) Received: from netrinsics.com([202.106.16.220]) by public.bta.net.cn(JetMail 2.5.3.0) with SMTP id jmb39d71645; Sun, 1 Oct 2000 05:07:55 -0000 Received: (from robinson@localhost) by netrinsics.com (8.11.0/8.9.3) id e9159MK03344 for freebsd-security@freebsd.org; Sun, 1 Oct 2000 13:09:22 +0800 (+0800) (envelope-from robinson) Date: Sun, 1 Oct 2000 13:09:22 +0800 (+0800) From: Michael Robinson Message-Id: <200010010509.e9159MK03344@netrinsics.com> To: freebsd-security@freebsd.org Subject: KAME IPSEC with ipnat Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Just a pointer for anyone trying to get KAME IPSEC to work with ipnat: In order for the IPSEC "tunnellization" policy to take effect on a packet, it has to be routed to an interface. In many cases, you'll want your VPN gateway to also serve as a NAT gateway. However, ipnat only supports source address based policies; everything going out your outbound interface will be natified before it can be tunnelized, and an natified packet won't match your tunnelization policy. The simple solution is to route tunnel-bound VPN packets to the loopback interface: % route add 172.16.0.0 -netmask 0xffffff00 -interface lo0 These packets then get intercepted by the IPSEC layer, encapsulated, and sent out according to the SPD configuration. -Michael Robinson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message