From owner-freebsd-security Thu Jul 22 5:40: 4 1999 Delivered-To: freebsd-security@freebsd.org Received: from lily.ezo.net (lily.ezo.net [206.102.130.13]) by hub.freebsd.org (Postfix) with ESMTP id 3A87414D8F for ; Thu, 22 Jul 1999 05:39:55 -0700 (PDT) (envelope-from jflowers@ezo.net) Received: from lily.ezo.net (jflowers@localhost.ezo.net [127.0.0.1]) by lily.ezo.net (8.8.7/8.8.7) with SMTP id IAA18406; Thu, 22 Jul 1999 08:39:06 -0400 (EDT) Date: Thu, 22 Jul 1999 08:39:05 -0400 (EDT) From: Jim Flowers To: skip-info@skip-vpn.org, freebsd-security@freebsd.org Subject: SKIP and NAT nomadic server - howto (long) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Skip and NAT are two very popular strategies for building secure networks with FreeBSD. They are sometimes believed to be incompatable when applied to the same interface. They will work together, however, when correctly configured. This document addresses the reference implementation of SKIP (1.0) and natd as implemented through ipfw. The key to understanding the operation of SKIP and NAT in parallel is to realize that inbound packets traverse the ipfw ruleset twice - once as an encapsulated packet and once as an de-encapsulated packet with the original destination address restored. Outbound packets, on the other hand, make a single pass in the unencapsulated state. This understanding can be used to advantage in building a nomadic SKIP server. A nomadic SKIP server allows any host equipped with a SKIP client to connect to the Internet (eg. via a dialup connection to an ISP) and then establish a secure connection to the nomadic SKIP server allowing full access to a Local Area Network. Because the remote host may have a different IP address each time it connects it is known as a nomad and its KeyID is used for identification rather than the IP address identification normally used to establish authenticity. The primary difficulty in setting up a nomadic server in conjunction with NAT is not in reaching in to the LAN but in returning a response to the remote host. The remote host IP address cannot, by definition, be known in advance. Further - authentication of the remote host and identification of its IP address by the SKIP module does not proceed to update the routing tables in the kernel. A LAN host receiving a connection request has insufficient information to reply to the remote host either via a static route or by dynamic routing. This leads to the requirement that the nomadic server must be in-line between the Internet and the LAN so that all packets not destined for the LAN are routed to the nomadic server by the gateway address in the LAN host. The second requirement is to prevent NAT from interfering. NAT does not bother the SKIP pass as the packet header is directed to the nat/skiphost. You can count the inbound SKIP packets as they can be identified by the SKIP protocol (57). Use an ipfw rule before the NAT rule such as: 00010 allow skip from any to any in recv fxp0 00100 divert 8668 ip from any to any via fxp0 assuming that skip is identified as 57 in /etc/protocols. A rule is required for the de-encrypted packets to allow them to be forwarded to the LAN by the routing mechanism without interference from NAT during the second pass: 00010 allow skip from any to any in recv fxp0 00020 allow ip from any to 192.168.0.0/24 in recv fxp0 00100 divert 8668 ip from any to any via fxp0 Now you can have nomadic hosts connect securely as part of the LAN and hosts on the LAN can continue to access the Internet through NAT. Of course, you have to configure the skiphost ACL correctly and setup the SKIP client on the nomad to match but that's covered in the documentation. Jim Flowers #4 ISP on C|NET, #1 in Ohio To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message