> 13 mars 2018 kl. 11:56 skrev Marc Peters <m...@mpeters.org>:
>
> On Tue, Mar 13, 2018 at 10:24:43AM +0100, Remi Locherer wrote:
>>> 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.
>
> Our setup relies on gif interfaces and ipsec in transport mode, too. When
> setting this up, we had issues with the gre setup and gre packets itself
> brings in more headers, which would reduce the payload. That's why we are
> using ipsec (in transport mode) protected gif tunnels for ospf and bgp.
>
> Best,
> Marc
>
I moved over to etherip(4) some time ago. In transition to etherip, combo of
etherip on one side and gif on another worked well.
I also remember announcement of gif(4) to be retired.
HISTORY
The gif device first appeared in WIDE hydrangea IPv6 kit.
Previously, gif supported RFC 3378 EtherIP tunnels over bridge(4)
interfaces. This is now handled by etherip(4).
//mxb
