gif(4) changes vs tunnelbroker

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

gif(4) changes vs tunnelbroker

Pavel Korovin
Dear all,

After upgrading several hosts to -current I noticed that all my IPv6 tunnels
via tunnelbroker stopped working. Recently introduced changes to gif(4) (since
late December 2017) are too complex for me to grasp, maybe anybody on the list
can advise.

--
With best regards,
Pavel Korovin

Reply | Threaded
Open this post in threaded view
|

Re: gif(4) changes vs tunnelbroker

David Gwynne-2


> On 27 Feb 2018, at 4:10 am, Pavel Korovin <[hidden email]> wrote:
>
> Dear all,
>
> After upgrading several hosts to -current I noticed that all my IPv6 tunnels
> via tunnelbroker stopped working. Recently introduced changes to gif(4) (since
> late December 2017) are too complex for me to grasp, maybe anybody on the list
> can advise.

hi pavel,

there was a window where gif only allowed configuration of the tunnel parameters while the interface was down, but still implicitly brought the interface up when addresses were configured. a lot of gif configs (or tunnel configs generally) have the ips set before the tunnel, so they'd go up, and then prevent configuration.

this has been fixed in -current, but a snap with the fix may not have made it out.

if this isn't the problem, can you send me your config and the state of the gif interfaces that are at fault and i'll see what else i broke.

cheers,
dlg

>
> --
> With best regards,
> Pavel Korovin
>

Reply | Threaded
Open this post in threaded view
|

Re: gif(4) changes vs tunnelbroker

Pavel Korovin
On 02/28, David Gwynne wrote:
> what is the status of sysctl net.inet.ipip ?

David, thank you! That was easy :)
Sorry for the noise.

$ sysctl net.inet.ipip.allow
net.inet.ipip.allow=0
# sysctl -w net.inet.ipip.allow=1
net.inet.ipip.allow: 0 -> 1
$ ping6 www.google.com
PING www.google.com (2a00:1450:4013:c01::67): 56 data bytes
64 bytes from 2a00:1450:4013:c01::67: icmp_seq=0 hlim=48 time=40.500 ms
64 bytes from 2a00:1450:4013:c01::67: icmp_seq=1 hlim=48 time=40.645 ms
^C
--- www.google.com ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 40.500/40.573/40.645/0.073 ms

--
With best regards,
Pavel Korovin

Reply | Threaded
Open this post in threaded view
|

Re: gif(4) changes vs tunnelbroker

Andreas Bartelt
On 02/27/18 22:35, Pavel Korovin wrote:

> On 02/28, David Gwynne wrote:
>> what is the status of sysctl net.inet.ipip ?
>
> David, thank you! That was easy :)
> Sorry for the noise.
>
> $ sysctl net.inet.ipip.allow
> net.inet.ipip.allow=0
> # sysctl -w net.inet.ipip.allow=1
> net.inet.ipip.allow: 0 -> 1
> $ ping6 www.google.com
> PING www.google.com (2a00:1450:4013:c01::67): 56 data bytes
> 64 bytes from 2a00:1450:4013:c01::67: icmp_seq=0 hlim=48 time=40.500 ms
> 64 bytes from 2a00:1450:4013:c01::67: icmp_seq=1 hlim=48 time=40.645 ms
> ^C

I'm also observing a breakage of a previously working IPv6 tunnelbroker
config on current (problem introduced since at least Feb, 23rd).

The combination of two things made it work again (or at least works
around the underlying problem):
1) sysctl net.inet.ipip.allow=1 [not yet documented at
www.openbsd.org/faq/current.html]
2) removing ``set state-policy if-bound'' from my pf.conf [which always
worked before with the same tunnelbroker setup]

According to pflog(4), a ping6 to some destination now looks buggy to me:
- outgoing icmp6 echo request is only visible on gif(4)
- incoming icmp6 echo reply is only visible on the underlying physical
interface of gif(4)
which blocks the ping6 in the case of ``set state-policy if-bound''.

Reply | Threaded
Open this post in threaded view
|

Re: gif(4) changes vs tunnelbroker

David Gwynne-2

> On 1 Mar 2018, at 02:22, Andreas Bartelt <[hidden email]> wrote:
>
> On 02/27/18 22:35, Pavel Korovin wrote:
>> On 02/28, David Gwynne wrote:
>>> what is the status of sysctl net.inet.ipip ?
>> David, thank you! That was easy :)
>> Sorry for the noise.
>> $ sysctl net.inet.ipip.allow
>> net.inet.ipip.allow=0
>> # sysctl -w net.inet.ipip.allow=1
>> net.inet.ipip.allow: 0 -> 1
>> $ ping6 www.google.com
>> PING www.google.com (2a00:1450:4013:c01::67): 56 data bytes
>> 64 bytes from 2a00:1450:4013:c01::67: icmp_seq=0 hlim=48 time=40.500 ms
>> 64 bytes from 2a00:1450:4013:c01::67: icmp_seq=1 hlim=48 time=40.645 ms
>> ^C
>
> I'm also observing a breakage of a previously working IPv6 tunnelbroker config on current (problem introduced since at least Feb, 23rd).
>
> The combination of two things made it work again (or at least works around the underlying problem):
> 1) sysctl net.inet.ipip.allow=1 [not yet documented at www.openbsd.org/faq/current.html]
> 2) removing ``set state-policy if-bound'' from my pf.conf [which always worked before with the same tunnelbroker setup]
>
> According to pflog(4), a ping6 to some destination now looks buggy to me:
> - outgoing icmp6 echo request is only visible on gif(4)
> - incoming icmp6 echo reply is only visible on the underlying physical interface of gif(4)
> which blocks the ping6 in the case of ``set state-policy if-bound''.

i found what i think is the problem.

it turns out the net.inet.ipip.allow sysctl was a red herring. it controls the processing of ipip by the network stack, it is not related to whether gif should accept packets. the problem was i got the mapping of ip addresses in incoming packets to the addresses on the tunnels wrong.

this should be fixed in src/sys/net/if_gif.c r1.112.

sorry for the inconvenience.

dlg

Reply | Threaded
Open this post in threaded view
|

Re: gif(4) changes vs tunnelbroker

Andreas Bartelt
On 03/01/18 00:30, David Gwynne wrote:

>
>> On 1 Mar 2018, at 02:22, Andreas Bartelt <[hidden email]> wrote:
>>
>> On 02/27/18 22:35, Pavel Korovin wrote:
>>> On 02/28, David Gwynne wrote:
>>>> what is the status of sysctl net.inet.ipip ?
>>> David, thank you! That was easy :)
>>> Sorry for the noise.
>>> $ sysctl net.inet.ipip.allow
>>> net.inet.ipip.allow=0
>>> # sysctl -w net.inet.ipip.allow=1
>>> net.inet.ipip.allow: 0 -> 1
>>> $ ping6 www.google.com
>>> PING www.google.com (2a00:1450:4013:c01::67): 56 data bytes
>>> 64 bytes from 2a00:1450:4013:c01::67: icmp_seq=0 hlim=48 time=40.500 ms
>>> 64 bytes from 2a00:1450:4013:c01::67: icmp_seq=1 hlim=48 time=40.645 ms
>>> ^C
>>
>> I'm also observing a breakage of a previously working IPv6 tunnelbroker config on current (problem introduced since at least Feb, 23rd).
>>
>> The combination of two things made it work again (or at least works around the underlying problem):
>> 1) sysctl net.inet.ipip.allow=1 [not yet documented at www.openbsd.org/faq/current.html]
>> 2) removing ``set state-policy if-bound'' from my pf.conf [which always worked before with the same tunnelbroker setup]
>>
>> According to pflog(4), a ping6 to some destination now looks buggy to me:
>> - outgoing icmp6 echo request is only visible on gif(4)
>> - incoming icmp6 echo reply is only visible on the underlying physical interface of gif(4)
>> which blocks the ping6 in the case of ``set state-policy if-bound''.
>
> i found what i think is the problem.
>
> it turns out the net.inet.ipip.allow sysctl was a red herring. it controls the processing of ipip by the network stack, it is not related to whether gif should accept packets. the problem was i got the mapping of ip addresses in incoming packets to the addresses on the tunnels wrong.
>
> this should be fixed in src/sys/net/if_gif.c r1.112.
>

yes, thanks -- it now works again with state-policy if-bound in pf.conf
and net.inet.ipip.allow=0