Date: Thu, 26 Nov 1998 01:08:27 -0500 From: "Jim Flowers" <jflowers@ezo.net> To: <skip-info@skip.org> Cc: <freebsd-questions@FreeBSD.ORG> Subject: SKIP Headscratcher (Long - and knotty) Message-ID: <01be1903$2f07f700$dae95d18@violet.neo.lrun.com>
next in thread | raw e-mail | index | archive | help
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 <jflowers@ezo.net>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01be1903$2f07f700$dae95d18>