blob: eb3518a56ddf19613736de9832ae0dafc9061204 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
|
diff -ur --unidirectional-new-file skipsrc-1.0.orig/doc/README.FreeBSD+NAT work.new/doc/README.FreeBSD+NAT
--- skipsrc-1.0.orig/doc/README.FreeBSD+NAT Wed Dec 31 16:00:00 1969
+++ work.new/doc/README.FreeBSD+NAT Mon Jan 24 12:35:42 2000
@@ -0,0 +1,65 @@
+Using SKIP and FreeBSD's NAT (Network Address Translation) together
+-------------------------------------------------------------------
+
+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 <jflowers@ezo.net>
+#4 ISP on C|NET, #1 in Ohio
+
|
