Re: some ICMPv6 messages don't make it through SNAT

On 3/13/24 16:36, Tuomo Soini wrote:
> On Wed, 13 Mar 2024 15:37:31 +0100
> Uwe Behle <[email protected]> wrote:
> 
>> Good afternoon,
>>
>> first, the mandatory information; for brevity since the problem lies
>> in ipV6, for V6 only:
>>
>> shorewall6 version
>> 5.2.8
> 
> Shorewall especially has rules to allow required ICMPv6 messages so
> shorewall is not blocking those. Only software issue there could be
> would be netfilter not being able to relate those icmp packets to your
> connection but I'd expect much more than this only to be broken in this
> case.
> 
> Because path mtu discovery is completely separate for both
> directions in ipv6, issue can be in either end.
> 
> In your case, you send packet over vpn - and sending packet wouldn't
> work if you'd block packet too big icmp. So because you can send
> packets out, problem is other direction.
> 
> Unlike IPv4, IPv6 does separate path mtu discovery for packets coming
> from responder to you, and machine on the other end of VPN is sending
> ICMPv6 Packet too big to the server when server try to respond you with
> 1500 MTU packet. So most likely packets from your other vpn end are
> filtered. That is if I understand your config correctly.
> 
> I know at this time whole azure is broken for IPv6 because they block
> packet too big icmpv6. So you can't reach any of their servers with
> IPv6 behind VPN.
> 
Hi Tuomo,

To clarify the setup:
|tunnel-end(AMS2) ----Interface(vmbr2)|___|Interface(eth0)---- browser|
        machine A                               machine B


My understanding is that when the browser opens test-ipv6.com it loads 
the necessary java-scripts and then sends packets via these java scripts 
to remote systems through the network interface eth0 on machine B.

This is then forwarded by machine A and SNATted through the tunnel.
The diagnosis is then derived from the response to the browser from the 
returned packets.

So for the long packets it uses this (seen in debug-mode of the browser)
"GET": {
		"scheme": "https",
		"host": "mtu1280.vm3.test-ipv6.com",
		"filename": "/images-nc/hires_ok.png",
		"query": {
			"": "",
			"fill": "xxxx.... very long string... xxxx"
		"testdomain": "test-ipv6.com",
			"testname": "test_v6mtu_img"
		}
	}

and then expects this "packet too long" resonse, which never arrives 
until the timeout is reached.

I can see this response at my end of the vpn tunnel (AMS2) and would 
expect it to be un-NATted and forwarded to the originator (the browser 
java script), which is behind the interface vmbr2. This does not happen.

The icmp6 arrives at AMS2 (mach. A) but is never seen at vmbr2 (mach. A)
and of course not at eth0 (mach. B) or the browser.

This tells me that everything works (unfiltered) as it should up to 
Interface AMS2.

In the meantime I noticed that there are entries in a log 
(pve-firewall.log) which I did not configure (the system is a proxmox 
setup):
0 6 - 13/Mar/2024:16:19:50 +0000 Sh6:rplog:DROP:IN=AMS2 
SRC=2001:470:1:18::3:1280 DST=fdbf:1d37:bbe0:0:48::35 LEN=1240 TC=0 
FLOWLBL=0 HOPLIMIT=240 PROTO=ICMPV6 TYPE=2 CODE=0 MTU=1280

This looks like a smoking gun to me - however I'm puzzled why these are 
dropped and not logged in my standard logfile...

Kind regards,

Uwe