IPsec, gif and packet flow

[Nikolay Sturm]

Hi!

I have the following setup, that i am not sure of whether it is supposed
to be this way and I just don't get it or whether this is some sort of
bug. If someone could enlighten me...

IPsec-ESP-Tunnel between IPa and IPb (OpenBSD 3.2-stable/i386).
gif-tunnel inside with IPa and IPb as the physical addresses and IPaa
and IPbb as logical(?) addresses.

Packet flow from observation:

IPaa -> gif0 -> enc0 -> ... -> enc0 -> IPbb

IPaa <- enc0 <- ... <- enc0 <- gif0 <- IPbb

My problem lies in the traffic entering the gif-tunnel through gif0
but being emitted by enc0. Is this the way it's supposed to be?

bye,

Nikolay

[Stephen J. Bevan]

Post by Nikolay Sturm
I have the following setup, that i am not sure of whether it is supposed
to be this way and I just don't get it or whether this is some sort of
bug. If someone could enlighten me...

Unless you have a specific reason for using gif then I'd leave it out
and just use IPsec tunnel mode if you are trying to do subnet<->subnet
or IPsec transport mode if you just want the two hosts to communicate
securely.

[Nikolay Sturm]

Post by Stephen J. Bevan

Post by Nikolay Sturm
I have the following setup, that i am not sure of whether it is supposed
to be this way and I just don't get it or whether this is some sort of
bug. If someone could enlighten me...

Unless you have a specific reason for using gif then I'd leave it out
and just use IPsec tunnel mode if you are trying to do subnet<->subnet
or IPsec transport mode if you just want the two hosts to communicate
securely.

I need the gif tunnel, it's somewhat complicated. :)

bye,

Nikolay

[Stephen J. Bevan]

Post by Nikolay Sturm

Post by Stephen J. Bevan
Unless you have a specific reason for using gif then I'd leave it out
and just use IPsec tunnel mode if you are trying to do subnet<->subnet
or IPsec transport mode if you just want the two hosts to communicate
securely.

I need the gif tunnel, it's somewhat complicated. :)

Running a routing daemon on your gif interfaces perhaps? Anyway, if
you don't use IPsec and instead just use gif to get IP-in-IP does
everything work fine?

[Nikolay Sturm]

If you don't use IPsec and instead just use gif to get IP-in-IP does
everything work fine?

Yup, using a gif-tunnel without IPsec the traffic emerges from gif0,
while it emerges from enc0 with IPsec.

bye,

Nikolay

[Stephen J. Bevan]

Post by Nikolay Sturm

If you don't use IPsec and instead just use gif to get IP-in-IP does
everything work fine?

Yup, using a gif-tunnel without IPsec the traffic emerges from gif0,
while it emerges from enc0 with IPsec.

I had to set this up to see what you meant and at first I didn't see
it since I was running tcpdump on the sender not the receiver. Here's
my setup :-

10.200.0.1 gif0
| A OpenBSD 3.2/x86 release
192.168.2.1 xl0
|
switch
|
192.168.2.254 fxp0
| B OpenBSD 3.1/x86 snapshot from August
10.100.0.1 gif0

If I do :-

A$ ping 10.100.0.1

then a tcpdump on both gif0 interfaces shows the packet being sent and
received. If I then create a transport mode IPsec connection between
192.168.2.254<->192.168.2.1 and do the ping again then there is no
change on the sender, the packets still enter and exit gif0. However,
on the receiver gif0 stops seeing the inbound ping and only shows the
outgoing reply, i.e. running a tcpdump on gif0 on B shows :-

# tcpdump -ni gif0
tcpdump: listening on gif0
14:55:16.370494 10.100.0.1 > 10.200.0.1: icmp: echo reply
14:55:17.380509 10.100.0.1 > 10.200.0.1: icmp: echo reply

On enc0 on the receiver both the inbound and outbound packets show up
which I guess is what you meant by the packet exiting the enc0
interface. The packets make it back correctly so the sender doesn't
notice the difference. However, anything on the receiver that is
specifically listening on gif0 will have a problem (routing daemon?).

A ping in the other direction shows the same thing so it shows up in
both the 3.1 snapshot and 3.2. Unless anyone wants to defend the
behaviour I'd submit a bug report if you haven't already done so
and/or check -current to see if it hasn't already been fixed.