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

     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.


Reply via email to