On 03/01/18 00:30, David Gwynne wrote:
>
>> On 1 Mar 2018, at 02:22, Andreas Bartelt <obsd@bartula.de> 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
No comments:
Post a Comment