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  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

Re: gif(4) changes vs tunnelbroker

[David Gwynne]

> On 1 Mar 2018, at 02:22, Andreas Bartelt  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

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''.

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

Re: gif(4) changes vs tunnelbroker

[David Gwynne]

> On 27 Feb 2018, at 4:10 am, Pavel Korovin  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
> 

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