https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291617
Bug ID: 291617
Summary: pf: NAT64 af-to doesn't generate ICMPv6 packet too big
errors
Product: Base System
Version: 16.0-CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
consider a NAT64 router with an "internal" interface (nat64b) with MTU 1500,
and an "external" interface (epair0a) with MTU 1280:
nat64b: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0
mtu 1500
epair0a: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric
0 mtu 1280
when attempting to route a 1400-byte ICMP echo request via normal IPv4 routing,
the MTU mismatch causes the kernel to generate an ICMP fragmentation required
error (which should cause the originating host to attempt path MTU discovery):
18:39:58.749129 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP
(1), length 1428)
3.3.3.3 > 1.1.1.1: ICMP echo request, id 59221, seq 12, length 1408
18:39:58.749147 IP (tos 0x0, ttl 64, id 52530, offset 0, flags [none], proto
ICMP (1), length 596)
10.0.0.1 > 3.3.3.3: ICMP 1.1.1.1 unreachable - need to frag (mtu 1280),
length 576
IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length
1428)
3.3.3.3 > 1.1.1.1: ICMP echo request, id 59221, seq 12, length 1408
with normal IPv6 routing (no NAT64), an equivalent ICMPv6 error is generated:
18:45:29.734984 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1408)
fd00:0:0:1::c > 2001:db8::1: [icmp6 sum ok] ICMP6, echo request, id 22058, seq
0
18:45:29.735044 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1240)
fe80::2 > fd00:0:0:1::c: [icmp6 sum ok] ICMP6, packet too big, mtu 1280
however, when the packet is sent to 64:ff9b::/96 and is translated by pf's
"af-to inet", no error is generated:
18:43:41.481308 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1408)
fd00:0:0:1::c > 64:ff9b::101:101: [icmp6 sum ok] ICMP6, echo request, id 22022,
seq 0
18:43:42.491614 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1408)
fd00:0:0:1::c > 64:ff9b::101:101: [icmp6 sum ok] ICMP6, echo request, id 22022,
seq 1
18:43:43.514269 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1408)
fd00:0:0:1::c > 64:ff9b::101:101: [icmp6 sum ok] ICMP6, echo request, id 22022,
seq 2
instead, the router attempts to forward the packet, even though this can never
succeed (confirmed by "output error" counter on epair0a incrementing for each
ping packet). this probably breaks path MTU discovery over the NAT, although i
don't have a production system to test that on.
tested on main (amd64) as of yesterday using the pf rule:
pass in on nat64b inet6 from any to 64:ff9b::/96 af-to inet from 10.0.0.1/32
--
You are receiving this mail because:
You are the assignee for the bug.
