From owner-freebsd-questions Wed Nov 25 22:08:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA28654 for freebsd-questions-outgoing; Wed, 25 Nov 1998 22:08:36 -0800 (PST) (envelope-from owner-freebsd-questions@FreeBSD.ORG) Received: from lily.ezo.net (lily.ezo.net [206.102.130.13]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA28649 for ; Wed, 25 Nov 1998 22:08:34 -0800 (PST) (envelope-from jflowers@ezo.net) Received: from violet.neo.lrun.com (c3-1d218.neo.rr.com [24.93.233.218]) by lily.ezo.net (8.8.7/8.8.7) with SMTP id BAA23267; Thu, 26 Nov 1998 01:08:20 -0500 (EST) From: "Jim Flowers" To: Cc: Subject: SKIP Headscratcher (Long - and knotty) Date: Thu, 26 Nov 1998 01:08:27 -0500 Message-ID: <01be1903$2f07f700$dae95d18@violet.neo.lrun.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am using the FreeBSD 2.2.7 port of SKIP 1.0 to construct a VPN between networks over the Internet. The SKIP box sits on a perimeter network at each site and tunnels both the firewall router perimeter interface address (routable) and hosts on the internal network (non-routable) to the distant network. ========ether0======== 206.151.178.0/29 198.2.27.0/29 ============ether0============ |\ |\ |\ |\ | .2 | .1 | .1 | .2 [SKIP] [Router]-------------------------Internet---------------------------[Router] [SKIP] | 0.254 | 0.254 |/ |/ ========ether1========10.0.0.0/23 10.0.0.2/23 ============ether1============ | | [Hosts] [Hosts] The routes have to be set up carefully so that packets destined for the distant network are routed to the skiphost for processing. The router address is included so that it can be used as a diagnostic tool for testing the VPN. The system has worked well in this configuration for more than a year. Now I have added another node, as shown in the ascigram that is currently in the testing phase. It is configured the same as the others but is half-way around the world, about 15 hops. The curious thing is that the VPN works fine, as long as I am pinging the router ether0 interface but not when pinging a host address on the internal network or the ether1 interface (same thing). Tracing the packets on the distant firewall router confirms that the encapsulated pings are being received and forwarded to the skiphost, that cleartext packets are being returned and forwarded to the target host, that cleartext return packets are being received and forwarded to the skiphost and that the encapsulated return packets are being received and sent out the Internet interface. But, they never get to the other end !!! Thought it might be ttls set to low but the target host is starting the returns at 128, which should be plenty. Another observation. A traceroute to a host on the internal network fails to respond - again I can follow the time exceeded icmp packets back to where they are injected into the Internet but never make it to the other end. But, wonder of wonders - a tracaeroute to the ether1 interface succeeds. Why? Because the source address for the time exceeded packets being returned is set to the ether0 address by the firewall router (just the way it is designed). Other than the 1 hop difference in the ttl, I think this can be the only difference in the two traceroute responses. So the only conclusion I can draw is that SKIP and the VPN is operating just as designed but some router (or routers) somewhere on the Internet is noting the non-routable IP address for the SOURCE ADDRESS and is discarding the packets instead of forwarding them. I would appreciate any ideas or observations or additional testing that I could try. I think my reasoning is sound but I was not aware that routers might look at source addresses to determine eligibility for discard. I suppose I will have to apply the patch to use the routable skiphost address for the source address but I don't relish doing that remotely. Thanks for any wisdom. Jim Flowers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message