NetBSD Problem Report #9920

Received: (qmail 10886 invoked from network); 18 Apr 2000 03:59:18 -0000
Message-Id: <200004172355.TAA01027@this>
Date: Mon, 17 Apr 2000 19:55:54 -0400 (EDT)
From: Charlie Root <root@squooshy.com>
Reply-To: atatat@netbsd.org
To: gnats-bugs@gnats.netbsd.org
Subject: gre and ipip documentation not complete, wrong, or something
X-Send-Pr-Version: 3.95

>Number:         9920
>Category:       kern
>Synopsis:       gre and ipip documentation not complete, wrong, or something
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          doc-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Apr 18 04:00:00 +0000 2000
>Closed-Date:    
>Last-Modified:  Thu May 22 07:14:46 +0000 2003
>Originator:     Andrew Brown
>Release:        1.4X as of 20000416
>Organization:
	none...just me.
>Environment:
System: NetBSD this 1.4X NetBSD 1.4X (THAT) #2: Sun Apr 16 15:13:55 EDT 2000 root@this:/usr/src/sys/arch/i386/compile/THAT i386


>Description:

	i figured i'd set up a tunnel (or two) since i have current at
home and it ought to be fun.  man gre.  okay...played around for a
bit.  got it going a few hours later.  then broke it.  got it going
again the next day (after a cvs update, a new kernel, and a new
userland build, but i don't think that's it).  conclusions:

	gre: seems to work fine, even if the documentation leaves a little
		and isn't quite right elsewhere
	ipip: seems to send but not receive.

>How-To-Repeat:

	read docs.  try it.  become confused.  periodically lament the
lack of bpf support for gre and ipip interfaces and then wonder what
that would do for you anyway.

>Fix:

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.
	* some ciscos apparently don't support the ip mobility
protocol.
	* the example configuration for the remote netbsd tunnel
endpoint looks a little incomplete, nut i've not tried it, so i can't
say for sure.

on ipip.4

	* the cisco configuration given is lacking

		tunnel mode ipip

which will keep it from working properly.  cisco tunnels default to
gre encapsulation.
	* i can apparently send, but not receive.

note: i was just gonna send some man page patches (and i will) but i'm
too tired right now to think in roff.  :)
>Release-Note:
>Audit-Trail:

From: woods@weird.com (Greg A. Woods)
To: gnats-bugs@gnats.netbsd.org (NetBSD GNATS submissions and followups),
	netbsd-bugs@NetBSD.ORG (NetBSD Bugs and PR posting List)
Cc:  
Subject: Re: kern/9920: gre and ipip documentation not complete, wrong, or something
Date: Tue, 18 Apr 2000 21:58:01 -0400 (EDT)

 [ 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>
>Unformatted:

Home	PR Database Search