Date: Wed, 10 Mar 1999 10:53:45 -0500 From: "Jim Flowers" <jflowers@ezo.net> To: <freebsd-hackers@freebsd.org>, "Terry Glanfield" <terry@ppsl.demon.co.uk> Subject: Re: Tunnel loopback Message-ID: <004301be6b0e$2efd77f0$23b197ce@crocus.ezo.net>
next in thread | raw e-mail | index | archive | help
An interesting approach but I'm having difficulty understanding your description. See below. -----Original Message----- From: Terry Glanfield <terry@ppsl.demon.co.uk> To: Jim Flowers <jflowers@ezo.net>; freebsd-hackers@freebsd.org <freebsd-hackers@freebsd.org> Date: Wednesday, March 10, 1999 8:47 AM Subject: Re: Tunnel loopback > pass in quick on ed0 to tun0 all This rule looks as if ipfw will accept all inbound packets received on any interface and exit thereby passing the packets up the stack. I am unfamiliar with the "quick" and "on" keywords; they don't appear in the ipfw man page. Also tun0 is not a legal choice for the dst argument which requires some form of IP address or keywords "not" and "any". Is this a special version of ipfw? Quick and on don't work on mine > >I have a rule on the external interface to redirect SKIP packets to >the tunnel: > > pass in quick on ed1 to tun0 proto skip all Again, I don't know the "quick" and "on" keywords but the "pass" (alias to allow) action is only for matching. It doesn't do any destination address or port redirection as do pipe, divert, tee and fwd. Won't the "all" keyword (matches every ip packet) override the proto skip specification? > >Similarly for UDP port 1640. I've tested this and it works admirably >(except for the duplicate packets mentioned earlier). The object is >to move SKIP from its position closest to the wire to a point before >NAT occurs. Then, so long as the SKIP packets have a properly >rewritten source address and are not modified by NAT, all of the >problems you mention are addressed. Rewriting the source address isn't of much consequence as the far-end skiphost will restore the original when it unencapsulates the packet. The one exception to this is using a public address in place of a private address as some ISP's are discarding packets that have private addresses in the source. >Nomadic SKIP hosts on the >Internet should also be possible although I've not tried this yet. The main problem with a nomadic host is that at the nomad end the original packet source and the skiphost have the same IP number and, by definition, it is unknown in advance. Not a problem for a simple host-to-host network but definitely a routing problem for a single-interface nomadic server in a host-to-network tunnel topology. You have to figure out how to route return packets to the skiphost for processing and then route the same packets (now encrypted but with the same destination address) to the nomad (far-end) skiphost. > >Now, if only I could stop the duplicate packets bouncing around the >tunnel... > >> Were you able to get the FreeBSD Skip-1.0 port to compile on 3.1? > >Apparently it won't work with LKM and needs a KLM rewrite. You might want to check with Archie Cobbs <archie@whistle.com> to see if this is going to happen. I'm still using 2.2.8 which compiles OK. I'm beginning to think SKIP may be reaching end-of-life status with the vanishing of the mailing list and archive. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?004301be6b0e$2efd77f0$23b197ce>