On Wed, Jun 18, 2025 at 09:09:00PM +0200, Manuel Kuklinski wrote: > Hi! > > Am Mittwoch 18 Juni 2025 um 8:43:25 +1000, schrieb David Gwynne 3,1K: > > the net.inet.gre.allow=1 enables gre processing for both ipv4 and > > ipv6. > > O.K. - thank you for clarifying! > > > dlg@bgp0 ~$ ifconfig gre6 > > gre6: > > flags=248051<UP,POINTOPOINT,RUNNING,MULTICAST,AUTOCONF6TEMP,AUTOCONF6> mtu > > 1476 > > index 7 priority 0 llprio 6 > > encap: vnetid none txprio payload rxprio packet > > groups: gre > > tunnel: inet6 2001:db8:602:307:c153:217c:4841:6ec4 --> > > 2001:db8:602:307:2387:f6e:62ac:a02 ttl 64 nodf ecn > > inet6 fe80::250:56ff:fea1:5dc3%gre6 --> prefixlen 64 scopeid 0x7 > > > > dlg@bgp1 ~$ ifconfig gre6 > > gre6: > > flags=248051<UP,POINTOPOINT,RUNNING,MULTICAST,AUTOCONF6TEMP,AUTOCONF6> mtu > > 1476 > > index 8 priority 0 llprio 6 > > encap: vnetid none txprio payload rxprio packet > > groups: gre > > tunnel: inet6 2001:db8:602:307:2387:f6e:62ac:a02 --> > > 2001:db8:602:307:c153:217c:4841:6ec4 ttl 64 nodf ecn > > inet6 fe80::250:56ff:fea1:aebe%gre6 --> prefixlen 64 scopeid 0x8 > > This works from Host A (OpenBSD) to Host B (OpenBSD), but not from Host > A to Host C (Linux) :-( > > Tassilo from the Freetransit support (the gre(4) tunnel is for BGP) > replied to following: > > "And the other thing I notice is that our linux box sends ipv6 > destination options (so it's ipv6 hdr | destination opts | gre header), > while your end sends (ipv6 hdr | gre header). Maybe the ipv6 extension > header gets filtered at your end?" > > This is confusing for me ATM... He's ticking off checkboxes with > possible causes of the problem; I'd be happy, if you could explain this > open question / draw on your experience - thank you again for your time! > > (I don't know how to debug this with tcpdump from my machine, since I > don't have access to the Linux box)
you should be able to use tcpdump on your box to see the packets coming from the linux host. if you can find which interface the tunnel packets are entering the system with, then you should be able to catch some. the only reason they would be sending an ipv6 destination options header is if they're using some mobile ipv6 semantics to send a Home Address option. OpenBSD does not implement support for the Home Address option, so we drop the packet before we get to the GRE input processing. the only other options specified for an ipv6 destination option header is for padding, and we do support that. can your provider disable that feature on their end? dlg
