> On 11 Mar 2018, at 05:30, Atanas Vladimirov <vl...@bsdbg.net> wrote:
>
> On 2018-03-10 00:01, Remi Locherer wrote:
>>>
>> With below diff the setup works as expected: tcpdump shows OSPF hellos
>> on gif0 and ospfd sees the neighbour.
>> I don't think it's the correct fix though.
>> Index: if_gif.c
>> ===================================================================
>> RCS file: /cvs/src/sys/net/if_gif.c,v
>> retrieving revision 1.112
>> diff -u -p -r1.112 if_gif.c
>> --- if_gif.c 28 Feb 2018 23:28:05 -0000 1.112
>> +++ if_gif.c 9 Mar 2018 20:52:46 -0000
>> @@ -745,8 +745,8 @@ gif_input(struct gif_tunnel *key, struct
>> }
>> /* XXX What if we run transport-mode IPsec to protect gif tunnel ? */
>> - if (m->m_flags & (M_AUTH | M_CONF))
>> - return (-1);
>> + //if (m->m_flags & (M_AUTH | M_CONF))
>> + // return (-1);
>> key->t_rtableid = m->m_pkthdr.ph_rtableid;
>
> Hi Remi,
>
> Thanks for confirming that there is an issue and I'm not doing something
> wrong on my side.
> I'll try the diff as soon as possible.
it isnt clear to me how ipsec and gif(4) are supposed to interact. on the one
hand you have the gif(4) manpage saying this:
BUGS
There are many tunnelling protocol specifications, defined differently
from each other. gif may not interoperate with peers which are based on
different specifications, and are picky about outer header fields. For
example, you cannot usually use gif to talk with IPsec devices that use
IPsec tunnel mode.
so it's saying that ipsec tunnel mode and gif don't work, but then you have the
code that remi is disabling saying that gif and ipsec transport dont work.
i can understand the issue since a decrypted esp packet looks a lot like the
packets gif wants to handle. if we change to code or doco to make something
work, which way should we go?
right now i would use gre inside ipsec transport mode, not gif. it has the
benefit of working, and it is harder for traffic inside the tunnel to leak out
of ipsec. more specifically, gif handles 3 ip protocols, ipv4, ipv6, and mpls,
which are ip protocol numbers 4, 41, and 137 respectively. it is likely that
people could set up ipsec to protect ipv4, but forget about ipv6 and mpls. if
you then configure v6 or mpls on the gif interface, that traffic will leak.
gre on the other hand is a single ip protocol, so more straightforward to
protect. there's also a very clear line in the sand between the inner and outer
traffic, which esp tunnel and transport mode lack.
dlg
