> 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