[ On Monday, April 17, 2000 at 19:55:54 (-0400), Charlie Root wrote: ]
> Subject: kern/9920: gre and ipip documentation not complete, wrong, or something
>
> 	gre: seems to work fine, even if the documentation leaves a little
> 		and isn't quite right elsewhere

I should probably separately send-pr the following (if it's not already
been reported) but I won't just yet:  Improper use of GRE can easily and
quickly cause a panic in -current (at least as of Mar 20 sup).  The
problem seems to be that a route to the tunnel end-point (as specified
in the ifconfig command) needs to be present at the time the ifconfig is
run else it panics with "gre0: searchin a route to NNN.NNN.NNN.NNN".

I had this happen to me because I tried configuring GRE just like any
other interface with an "ifconfig_gre0" setting in /etc/rc.local.conf.
Even though this seems to have been done last (i.e. after both Ethernet
interfaces were configured and up), it still had trouble with the route.
In the end I had to put all the hooks, including the re-adjustment of my
default route to point through the tunnel, in /etc/netstart.local.
(Note that the default route I initially configured was out the public
interface anyway so if it had been in effect the panic message would
have been a lie.)

This should most definitely not be a panic.  The 

Here's more or less what I ended up doing (over and above the normal
configuration of the ethernet interfaces with an initial default route
pointing out the "outside" (@Home) interface):

	# Just to complicate things I have both a class-C and a /27
	# subnet routed through the tunnel, with my class-C being the
	# primary inside address, and one of the /27 addresses being the
	# tunnel end-point on my end and with an alias on the inside
	# interface.
	# 
	# alias 204.29.161.ccc on inside interface is tunnel endpoint
	# @Home interface is 24.nnn.nnn.4

	# first make sure we can talk to the public address of the host
	# handling the other end of the tunnel by adding a host route
	# pointing to the local gateway for the outside address....
	# (I don't know if this really has to be done first....)
	#
	route add -host 24.yyy.xxx.zzz 24.nnn.nnn.1

	# then bring up gre0 using the tunnel addresses
	#
	ifconfig gre0 inet 204.29.161.ccc 204.aaa.bbb.ddd netmask 255.255.255.255 link0 link1 up

	# do the rest of the GRE configuration using outside addresses
	#
	greconfig -v -i gre0 -s 24.nnn.nnn.4 -d 24.yyy.xxx.zzz

	# finally fix the default route to point through the tunnel
	# 
	route delete default
	route add default 204.aaa.bbb.ddd

	# add routes for subnets hosting @Home servers we use...
	# (all connections will be NATed if the come from the inside LAN)
	#
	# 24.2.9.0: mail.ym1.on.wave.home.com & news.ym1.on.wave.home.com
	route add -net 24.2.9.0 -netmask 255.255.255.0 24.nnn.nnn.1
	# 24.112.32.0: proxy.ym1.on.wave.home.com (also DNS)
	route add -net 24.112.32.0 -netmask 255.255.255.0 24.nnn.nnn.1

	# and a route for a couple of friends using @Home too
	#
	route add -host 24.abc.def.ghi 24.nnn.nnn.1
	route add -host 24.jkl.mno.pqr 24.nnn.nnn.1

> on gre.4
> 
> 	* the source and destination given to the ifconfig gre0
> command don't need to be the same as the source and destination given
> to the greconfig line.
> 	* the documentation should describe the difference between the
> addresses of the two endpoints and the addresses of the source and
> destination of the tunne.  specifically, the local tunnel endpoint
> will be the address used for local connections out over the tunnel,
> whereas the tunnel source will be the ip source address of the
> encapsulated packets.

Yes, this is very important too, for configurations such as mine where
I'm routing through a tunnel over someone else's network since you need
the GRE interface to appear as if it were a normal next-hop for the
routing of the tunnelled network.

The terminology is very confusing, at least to me.  It's not obvious by
the words alone which is an "end-point" and which is the "source or
destination" for the tunnel.  There seems to be disagreements in the
literature about which is which.  I have much better luck using the word
"tunnel" alone to describe the address of the GRE interface and then
describing the addresses used in the encapsulation headers as the
encapsulation headers.  I suppose if you describe it as an actual pipe
then the ends (end-points) of the pipe (i.e. the "outside") are the
encapsulation header addresses while the interfaces used to "route" into
and out of the tunnel (which goes through the pipe) are the
source/destination (aka payload) addresses.


There are other problems with GRE to do with the integration of
IP-Filter.  The packets coming in through the tunnel remain tagged with
the outside interface name and thus do not, from IP Filter's point of
view, appear to have come from the GRE interface.  This makes it very
diffucult to write full firewall rules on the tunnel box itself.

Of course the bug already mentioned in the manual page w.r.t. traceroute
not working is also very annoying.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>