On 3/13/24 16:36, Tuomo Soini wrote:
On Wed, 13 Mar 2024 15:37:31 +0100
Uwe Behle <shw...@behle.name> 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
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
