On 2018-03-13 07:28, David Gwynne wrote:
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.
BUGS is about one site using IPsec tunnel and the other site IPsec
transport with gif.
The problem reported by Atanas is about IPsec transport + gif on both
sites.
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,
yes ;-)
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.
I don't see the big difference here between gif and gre. To prevent
traffic
leave your box unprotected you have to setup pf rules in both cases.
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.
But gre alone does not protect the traffic! You still need esp transport
for protection.
My main point about this is:
The setup described by Atanas used to work. There are setups out there
(including mine) that are operational for years and rely on OSPF working
via gif + esp transport. With the current state of gif these setups will
break.
Regards,
Remi
