gre encap destination = point-to-point destination

[David Young]

I am trying to understand why one would configure a gre/gif tunnel
with encapsulation destination equal to the point-to-point destination.
E.g., on this interface, the encap destination, 10.0.0.2, is the same
as the point-to-point destination:

gre5006: flags=d051<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> mtu 1476
tunnel inet 10.0.0.1 --> 10.0.0.2
inet 10.0.0.3 -> 10.0.0.2 netmask 0xffffffff
inet6 fe80::a00:20ff:fef9:60ee%gre5006 -> prefixlen 64 scopeid 0x112d

To support this configuration, an author resorted to some cleverness that
it will be *tremendously* difficult to replicate in the New Model GRE,
which I intend both to simplify GRE, to support IPv6 encapsulation,
and to repair a bug in route caching[1].

Can anybody explain, what is use such a configuration as above? Is there
no other way to create a similar network?

Dave

[1] The bug I have in mind has the same flavor as the one in kern/3508.

[Ignatios Souvatzis]

Post by David Young
I am trying to understand why one would configure a gre/gif tunnel
with encapsulation destination equal to the point-to-point destination.
E.g., on this interface, the encap destination, 10.0.0.2, is the same
gre5006: flags=d051<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> mtu 1476
tunnel inet 10.0.0.1 --> 10.0.0.2
inet 10.0.0.3 -> 10.0.0.2 netmask 0xffffffff
inet6 fe80::a00:20ff:fef9:60ee%gre5006 -> prefixlen 64 scopeid 0x112d
[...]
Can anybody explain, what is use such a configuration as above? Is there
no other way to create a similar network?

Out of IPv4 addresses to assign to the target machine?

-is

[Michael van Elst]

Post by David Young
gre5006: flags=d051<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> mtu 1476
tunnel inet 10.0.0.1 --> 10.0.0.2
inet 10.0.0.3 -> 10.0.0.2 netmask 0xffffffff
inet6 fe80::a00:20ff:fef9:60ee%gre5006 -> prefixlen 64 scopeid 0x112d
Can anybody explain, what is use such a configuration as above? Is there
no other way to create a similar network?

Maybe 10.0.0.1 -> 10.0.0.2 is a point-to-point route itself or
the network filters other addresses? Then you have to tunnel
other addresses and this is one method to avoid additional
addresses on the target.

What exactly is the problem with this configuration?

[David Young]

Post by Michael van Elst

Post by David Young
gre5006: flags=d051<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> mtu 1476
tunnel inet 10.0.0.1 --> 10.0.0.2
inet 10.0.0.3 -> 10.0.0.2 netmask 0xffffffff
inet6 fe80::a00:20ff:fef9:60ee%gre5006 -> prefixlen 64 scopeid 0x112d
Can anybody explain, what is use such a configuration as above? Is there
no other way to create a similar network?

Maybe 10.0.0.1 -> 10.0.0.2 is a point-to-point route itself or
the network filters other addresses? Then you have to tunnel
other addresses and this is one method to avoid additional
addresses on the target.

This sounds like a hypothetical example. I am want to ehar from people
who are personally invested in this quirk of gre(4) operation, so that
I can understand why before I change it.

Post by Michael van Elst
What exactly is the problem with this configuration?

NetBSD will install a route to 10.0.0.2 that points at the tunnel
pseudo-interface. Thus, if you send a packet to 10.0.0.2, it ought to go
through the tunnel. The encapsulated packet, whose destination is also
10.0.0.2, ought to go through the tunnel again. The doubly-encapsulated
packet, too, will go out the tunnel again. That is, a reasonable
interpretation of this configuration is that it leads to recursion.
In fact, the same configuration of a gif(4) tunnel does lead to recursion.
Where gif(4) detects the recursion and drops the packet, gre(4) fiddles
with the routing lookup to break the recursion, leading to a surprising
and somewhat arbitrary routing of the encapsulated packet.

Dave

[David Young]

Post by David Young

Post by Michael van Elst

Post by David Young
gre5006: flags=d051<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> mtu 1476
tunnel inet 10.0.0.1 --> 10.0.0.2
inet 10.0.0.3 -> 10.0.0.2 netmask 0xffffffff
inet6 fe80::a00:20ff:fef9:60ee%gre5006 -> prefixlen 64 scopeid 0x112d
Can anybody explain, what is use such a configuration as above? Is there
no other way to create a similar network?

Maybe 10.0.0.1 -> 10.0.0.2 is a point-to-point route itself or
the network filters other addresses? Then you have to tunnel
other addresses and this is one method to avoid additional
addresses on the target.

This sounds like a hypothetical example. I am want to ehar from people

Translation, "I want to hear...".

Dave

[Gert Doering]

Post by Michael van Elst

Post by David Young
gre5006: flags=d051<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> mtu 1476
tunnel inet 10.0.0.1 --> 10.0.0.2
inet 10.0.0.3 -> 10.0.0.2 netmask 0xffffffff
inet6 fe80::a00:20ff:fef9:60ee%gre5006 -> prefixlen 64 scopeid 0x112d
Can anybody explain, what is use such a configuration as above? Is there
no other way to create a similar network?

What exactly is the problem with this configuration?

"Where do you send packets to 10.0.0.2 to"?

Sending through the tunnel (where the "inside" route points to) will
lead to infinite recursion.

Sending them via "outside" routes will mean "you can't ever reach the
inside point-to-point address of your tunnel peer via the tunnel".

One *could* solve that by sort of attaching flags to the packet that tell
the routing logic "I have been inside gre5006, do not consider gre5006
for further routing lookups", but that sounds massively ugly.

My vote would be to disallow such configurations - log a warning, and
set the tunnel interface to "DOWN".


Besides that: David, could you go into a bit more details about your
great GRE rewrite? I don't claim to understand all the kernel IP
routing / interface details - but I'm always interested in IPv6-related
work, and GRE tunnels are useful :-)

gert

[Ignatios Souvatzis]

Hi,

Post by Gert Doering
"Where do you send packets to 10.0.0.2 to"?
[...]
Sending through the tunnel (where the "inside" route points to) will
lead to infinite recursion.
Sending them via "outside" routes will mean "you can't ever reach the
inside point-to-point address of your tunnel peer via the tunnel".
[...]
My vote would be to disallow such configurations - log a warning, and
set the tunnel interface to "DOWN".

I was about to recommend asking Gert Doering as he's the only gre
user I know about; but if hi isn't, then I, too, am in favour of
disallowing such configurations at some level.

Regards,
-is

[Gert Doering]

Post by Ignatios Souvatzis

[ possibly recursive tunnel routing in gre(4) and hackish workarounds ]

I was about to recommend asking Gert Doering as he's the only gre
user I know about; but if hi isn't, then I, too, am in favour of
disallowing such configurations at some level.

*g* - thanks.

Actually I might be biased because I work too much with Cisco, and have
been hit on my head a number of times with the dreaded "tunnel disabled
due to recursive routing" error message.

While at it, the gre(4) man page needs serious rework - the configuration
example actually *suggests* that it might be a fairly normal thing to have
the same IP address for "tunnel inside destination" and "tunnel outside
destination":

-------- snip ---------
On host A (NetBSD):
# route add default B
# ifconfig greN create
# ifconfig greN A D netmask 0xffffffff linkX up
# ifconfig greN tunnel A D
# route add E D
-------- snip ---------

- just last week someone showed up on a Cisco mailing list with a
similarily broked gre(4) configuration [on FreeBSD]...

The second IPv4 example in the man page is much more useful.


Actually it might make lots of sense to be able to run gif(4) and gre(4)
tunnels "ip unnumbered" - don't attach a transit network to the "inside",
don't create any implicit routes, and enable setting of routes to
tunnel interfaces:

# route add -net 1.2.3.0 -netmask 255.255.255.0 dev gif0

I'm not sure whether this is possible today - the man page examples
all require a next-hop address, as in

# route add -inet6 0::0/0 2001:db8:ffff::2 -ifp greN

- which seems to imply that when I wrote that, just setting

# route add -inet6 0::0/0 -ifp greN

("I don't want to know or care what the other end's inside IP address
is - this is a point-to-point tunnel, just stuff the packet it, we don't
do any sort of layer2-next-hop resolution anyway")

didn't work. But that was quite a while ago.

gert

PS: the gif(4) man page could use some IPv6 examples :)
--
***@greenie.muc.de fax: [phone] http://alpha.greenie.net/mgetty/

If the presence of electricity can be made visible in any part of a circuit, I
see no reason why intelligence may not be transmitted instantaneously by
electricity. -- Samuel F. B. Morse

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Thor Lancelot Simon]

Post by Gert Doering
While at it, the gre(4) man page needs serious rework - the configuration
example actually *suggests* that it might be a fairly normal thing to have
the same IP address for "tunnel inside destination" and "tunnel outside

It was probably copied from the gif(4) manual page.

I doubt it matters much for gre, but if this configuration stops working
with gif, it will become _impossible_ to talk to IPsec peers which do not
implement transport mode.

I believe we don't run into the recursion with gif because of the (rather
frightening) way packets actually are fed into gif for encapsulation in
the IPsec case.

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Michael van Elst]

Post by Thor Lancelot Simon
IPsec tunnel mode uses the encapsulation code from gif(4).

Just to clarify, this is FAST_IPSEC code, not the regular KAME.

[Thor Lancelot Simon]

Post by Michael van Elst

Post by Thor Lancelot Simon
IPsec tunnel mode uses the encapsulation code from gif(4).

Just to clarify, this is FAST_IPSEC code, not the regular KAME.

No. See how far you get with tunnel mode, with a KAME kernel without
gif compiled into it.

[Michael van Elst]

Post by Thor Lancelot Simon

Post by Michael van Elst

Post by Thor Lancelot Simon
IPsec tunnel mode uses the encapsulation code from gif(4).

Just to clarify, this is FAST_IPSEC code, not the regular KAME.

No. See how far you get with tunnel mode, with a KAME kernel without
gif compiled into it.

I admit that I never tried it before, but it seems to work fine here.

henery% uname -a
NetBSD henery 3.1_RC4 NetBSD 3.1_RC4 (HENERY) #37: Wed Nov 8 00:31:43
CET 2006 ***@henery:/usr/obj/home/src/sys/arch/i386/compile/HENERY i386

henery% config -x | egrep 'IPSEC|gif'
options IPSEC # IP security
options IPSEC_ESP # IP security (encryption part; define w/IPSEC)
#options IPSEC_NAT_T # IPsec NAT traversal (NAT-T)
#options IPSEC_DEBUG # debug for IP security
#pseudo-device gif 4 # IPv[46] over IPv[46] tunnel (RFC1933)

henery% sudo setkey -D
Password:
10.27.5.8 10.27.5.1
esp mode=tunnel spi=5569397(0x0054fb75) reqid=0(0x00000000)
...
seq=0x000000d0 replay=4 flags=0x00000000 state=mature
created: Nov 8 00:33:31 2006 current: Nov 8 00:35:54 2006
...
10.27.5.1 10.27.5.8
esp mode=tunnel spi=7715566(0x0075baee) reqid=0(0x00000000)
...
seq=0x000000bf replay=4 flags=0x00000000 state=mature
created: Nov 8 00:33:31 2006 current: Nov 8 00:35:54 2006
...


Saying this, I don't know if FAST_IPSEC is even using gif(4).

[Thor Lancelot Simon]

Post by Michael van Elst

Post by Thor Lancelot Simon

Post by Michael van Elst

Post by Thor Lancelot Simon
IPsec tunnel mode uses the encapsulation code from gif(4).

Just to clarify, this is FAST_IPSEC code, not the regular KAME.

No. See how far you get with tunnel mode, with a KAME kernel without
gif compiled into it.

I admit that I never tried it before, but it seems to work fine here.

Yes. This seems to have changed quite a while ago, and I didn't notice.

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Gert Doering]

Hi,

Post by Thor Lancelot Simon

Post by Gert Doering
While at it, the gre(4) man page needs serious rework - the configuration
example actually *suggests* that it might be a fairly normal thing to have
the same IP address for "tunnel inside destination" and "tunnel outside

It was probably copied from the gif(4) manual page.

Yes, looks very much like it.

Post by Thor Lancelot Simon
I doubt it matters much for gre, but if this configuration stops working
with gif, it will become _impossible_ to talk to IPsec peers which do not
implement transport mode.

Is this for IPsec tunnel mode, implemented somehow via gif(4)?

If yes, it might be worth mentioning this in the gif(4) manpage :) - as
far as I understood it, I assumed gif(4) only did unencrypted IPv4/IPv6
over IPv4/IPv6 tunneling:

------------- snip --------------
DESCRIPTION
The gif interface is a generic tunneling pseudo device for IPv4 and IPv6.
It can tunnel IPv[46] traffic over IPv[46]. Therefore, there can be four
possible configurations. The behavior of gif is mainly based on RFC 2893
IPv6-over-IPv4 configured tunnel. gif can also tunnel ISO traffic over
IPv[46] using EON encapsulation.
------------- snip --------------

Post by Thor Lancelot Simon
I believe we don't run into the recursion with gif because of the (rather
frightening) way packets actually are fed into gif for encapsulation in
the IPsec case.

How exactly does this work?

gert

[Thor Lancelot Simon]

Post by Gert Doering

Post by Thor Lancelot Simon
I doubt it matters much for gre, but if this configuration stops working
with gif, it will become _impossible_ to talk to IPsec peers which do not
implement transport mode.

Is this for IPsec tunnel mode, implemented somehow via gif(4)?

IPsec tunnel mode uses the encapsulation code from gif(4). This makes
sense, since the resulting packets on the wire are identical no matter
whether one uses a transport-mode IPsec SA and a gif interface to
accomplish the inner encapsulation, or a tunnel-mode SA. In fact, it
might be considerably cleaner to explicitly configure cloning gif
interfaces for each tunnel-mode SA, because this avoids the ugly hack
used to route packets through the gif machinery by IPsec, and also
provides explicit filter points for the traffic before and after the
IPsec encapsulation or decapsulation.

Some IPsec peers don't implement transport mode and will negotiate
only tunnel mode with their own address as both inner and outer. If it
became impossible to get the gif code to handle such packets even when
called as it is from IPsec (where the policy code directs the packets
into the tunnel, bypassing normal routing lookups) we'd end up unable
to talk to such peers.

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Gert Doering
Besides that: David, could you go into a bit more details about your
great GRE rewrite? I don't claim to understand all the kernel IP
routing / interface details - but I'm always interested in IPv6-related
work, and GRE tunnels are useful :-)

I am about ready to work on this. Let me tell you what I have in mind.

Right now, gre(4) adds/removes encapsulating IP headers, it hooks
into protocol switches in order to "catch" packets sent to its IP
protocol numbers of interest, and it demultiplexes received packets.
We can do all of that with a socket. I will make gre use one.

A socket hides such details of its implementation from gre(4) as the
encapsulation type (IPv4, IPv6, UDP), the protocol hooks, and the
demultiplexing, so I can simplify gre and remove its "hooks" from the
IPv4 stack. Without adding new "hooks," I can add an IPv6 encapsulation
to gre---bonus!

Ok, so there is a catch: a raw IPv4 socket is not suitable for my purpose.
It is not "symmetrical": it removes the IPv4 header from received packets,
but it does not add the IPv4 header to transmitted packets. No other
IPv4 socket is suitable. I need to either add an option to the raw IPv4
socket that makes it supply the IPv4 header, or I need to introduce new,
symmetrical socket types---socket(PF_INET, SOCK_DGRAM, IPPROTO_GRE)?
I am inclined to add an option to the raw socket.

After I convert gre to use sockets, I will add to it the capability to
tunnel ethernet frames.

I believe gif(4) and etherip(4) deserve to be converted to use sockets,
too, but I may not tackle that.

Dave

[David Young]

Post by David Young
Ok, so there is a catch: a raw IPv4 socket is not suitable for my purpose.
It is not "symmetrical": it removes the IPv4 header from received packets,
but it does not add the IPv4 header to transmitted packets.

I misspoke. The received packets, not the transmitted packets, contain
an IP header.

Dave

[Greg Troxel]

Right now, gre(4) adds/removes encapsulating IP headers, it hooks
into protocol switches in order to "catch" packets sent to its IP
protocol numbers of interest, and it demultiplexes received packets.
We can do all of that with a socket. I will make gre use one.

I do not follow this. Would one then have to have a user-space program
and a tun device? Or would that then be possible, alongside the
current config? Or did you mean something else?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by David Young
Right now, gre(4) adds/removes encapsulating IP headers, it hooks
into protocol switches in order to "catch" packets sent to its IP
protocol numbers of interest, and it demultiplexes received packets.
We can do all of that with a socket. I will make gre use one.
I do not follow this. Would one then have to have a user-space program
and a tun device? Or would that then be possible, alongside the
current config? Or did you mean something else?

I mean that gre(4) will create a socket with socreate(), and then it
will use so->so_receive() and so->so_send() to receive and send packets.
This is the way that GRE in UDP tunnels work today.

Dave

[Bill Stouder-Studenmund]

Post by David Young
I am trying to understand why one would configure a gre/gif tunnel
with encapsulation destination equal to the point-to-point destination.
E.g., on this interface, the encap destination, 10.0.0.2, is the same
gre5006: flags=d051<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> mtu 1476
tunnel inet 10.0.0.1 --> 10.0.0.2
inet 10.0.0.3 -> 10.0.0.2 netmask 0xffffffff
inet6 fe80::a00:20ff:fef9:60ee%gre5006 -> prefixlen 64 scopeid 0x112d
To support this configuration, an author resorted to some cleverness that
it will be *tremendously* difficult to replicate in the New Model GRE,
which I intend both to simplify GRE, to support IPv6 encapsulation,
and to repair a bug in route caching[1].
Can anybody explain, what is use such a configuration as above? Is there
no other way to create a similar network?

I'm sorry for the 6-month delay in following up.

I can't see a reason for the exact above, because the boxes are all on the
same subnet.

I think a reason for having the inside and outside IPs the same is if you
have a box that's providing services and is also your tunnel end point.

To be honest, the reasons I can come up with also involve transport mode
IPsec. Putting them together, it's like having the hiding of NAT w/o
having NAT.

The real reason I could see this is if you had two paths to the other IP,
each with its own border box. Each one does a gre tunneling some addreses
to the end point, and it uses routing to decide which of your two routers
to send packets back to.

Transport mode IPsec plus GRE produces packets that look the same on the
wire as those from Tunnel mode IPsec. The difference is in the attached
policy. Transport mode + IP tunnelling lets you add all sorts of routing
on top of the tunnels.

Take care,

Bill

[Daniel Carosone]

Post by Bill Stouder-Studenmund
Transport mode IPsec plus GRE produces packets that look the same on the
wire as those from Tunnel mode IPsec. The difference is in the attached
policy. Transport mode + IP tunnelling lets you add all sorts of routing
on top of the tunnels.

Not just that; it also gives you several other benefits of having an
explicit interface to represent the tunnelling step separately from
the encryption step. In particular, you get an explicit inside-tunnel
MTU and explicit inside-tunnel ipf/pf filtering/NAT rules.

One of the common reasons to want to use the same inner and outer GRE
address relates to INADDR_ANY source address selection (and listening
sockets) for programs on the box itself. That can be worked around
with NAT on the gre interface, just as you would for ppp or any other
"WAN" interface where you don't really want to advertise/use the
link-segment address for application traffic (eg it belongs to your
isp and resolves to their PTR domain).

--
Dan.

[Jason Thorpe]

Post by Daniel Carosone
Not just that; it also gives you several other benefits of having an
explicit interface to represent the tunnelling step separately from
the encryption step. In particular, you get an explicit inside-tunnel
MTU and explicit inside-tunnel ipf/pf filtering/NAT rules.

Yah, I gotta say, I always thought tunnel mode IPsec was stupid.

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

Post by Jason Thorpe
Yah, I gotta say, I always thought tunnel mode IPsec was stupid.

I see your point, but note that tunnel mode IPsec lets you use the SPD
to choose the packets to which IPsec is applied, and to validate that
those packets coming out of the tunnel are also valid.
So you need firewall and routing and IP-IP and transport to replace it.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Daniel Carosone]

Post by Greg Troxel

Post by Jason Thorpe
Yah, I gotta say, I always thought tunnel mode IPsec was stupid.

I see your point, but note that tunnel mode IPsec lets you use the SPD
to choose the packets to which IPsec is applied, and to validate that
those packets coming out of the tunnel are also valid.

You can, but unfortunately the ipsec spd packet filter language is so
impoverished (no connection state tracking, etc..) that this is much
harder and less convenient than it should be. Essentially, it gets
used as a much blunter instrument than the other packet filter
languages available (ipf/pf).

The spd language is a good fit for saying things like "encrypt gre
transport between me and thee", though.

Post by Greg Troxel
So you need firewall and routing and IP-IP and transport to replace it.

Precisely; this is the desired basis of the exercise, rather than some
kind of overhead or disincentive cost. The point is to be able to use
these tools with ipsec, rather than in spite of it. Unifying the SPD
with the rest of the packet matching mechanism (eg, "encrypt" actions
as well as block or pass) would be very nice, but has not found an
interested and capable volunteer.

--
Dan.

[Jason Thorpe]

Post by Bill Stouder-Studenmund
Transport mode IPsec plus GRE produces packets that look the same on the
wire as those from Tunnel mode IPsec.

Not true.

Transport mode IPsec plus IP-in-IP produces packets that look the same
on the wire as those from Tunnel mode IPsec.

GRE != IP-in-IP

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de