[Bug 185633] [pf] scrubbing bug in transparent mode bug with bigger than MTU UDP packet
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Mon Aug 29 07:42:32 UTC 2016
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185633
Olivier Cochard <olivier at freebsd.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |olivier at freebsd.org
--- Comment #5 from Olivier Cochard <olivier at freebsd.org> ---
Let me restart my virtual-lab on -current (same version for all VMs):
root at VM2:~ # uname -a
FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r304964M: Sun Aug 28 21:49:48
CEST 2016
olivier at lame4.bsdrp.net:/usr/obj/BSDRP12.amd64/usr/local/BSDRP/BSDRP12/FreeBSD/src/sys/amd64
amd64
Simple lab diagram:
VM 1 (vtnet0)------(vtnet0) VM2 (vtnet1) -------- (vtnet1) VM 3
VM1 setup:
sysrc ifconfig_vtnet0="inet 10.0.0.1/24"
service netif restart
VM 2 setup:
sysrc ifconfig_vtnet0="up"
sysrc ifconfig_vtnet1="up"
sysrc cloned_interfaces="bridge0"
sysrc ifconfig_bridge0="addm vtnet0 addm vtnet1 up"
sysrc pf_enable=yes
cat > /etc/pf.conf <<EOF
set skip on lo0
scrub
pass
EOF
service netif restart
service pf start
VM 3 setup:
sysrc ifconfig_vtnet1="inet 10.0.0.3/24"
service netif restart
Now a standard ping works but not fragmented (same problem with UDP).
Example from VM1 to VM3:
root at VM1:~ # ping -c 1 10.0.0.3
PING 10.0.0.3 (10.0.0.3): 56 data bytes
64 bytes from 10.0.0.3: icmp_seq=0 ttl=64 time=0.258 ms
--- 10.0.0.3 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.258/0.258/0.258/0.000 ms
=> Works with "standard size" (non-fragmented) ICMP ping.
root@:~ # ping -c 1 -s 1500 10.0.0.3
PING 10.0.0.3 (10.0.0.3): 1500 data bytes
--- 10.0.0.3 ping statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss
=> But not with fragmented ICMP
A tcpdump on VM2 or VM3 give the same "corrupted" IP packet generated:
root at VM2:~ # tcpdump -vv -pnei vtnet1
tcpdump: listening on vtnet1, link-type EN10MB (Ethernet), capture size 262144
bytes
09:39:59.656215 20:00:40:01:33:fa > 45:00:05:dc:0d:24, ethertype Unknown
(0x0a00), length 1500:
0x0000: 0001 0a00 0003 0800 12d1 b907 0000 57c4 ..............W.
0x0010: 02ef 000a 16c8 0809 0a0b 0c0d 0e0f 1011 ................
0x0020: 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 ...............!
0x0030: 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 "#$%&'()*+,-./01
0x0040: 3233 3435 3637 3839 3a3b 3c3d 3e3f 4041 23456789:;<=>?@A
0x0050: 4243 4445 4647 4849 4a4b 4c4d 4e4f 5051 BCDEFGHIJKLMNOPQ
0x0060: 5253 5455 5657 5859 5a5b 5c5d 5e5f 6061 RSTUVWXYZ[\]^_`a
0x0070: 6263 6465 6667 6869 6a6b 6c6d 6e6f 7071 bcdefghijklmnopq
0x0080: 7273 7475 7677 7879 7a7b 7c7d 7e7f 8081 rstuvwxyz{|}~...
0x0090: 8283 8485 8687 8889 8a8b 8c8d 8e8f 9091 ................
0x00a0: 9293 9495 9697 9899 9a9b 9c9d 9e9f a0a1 ................
0x00b0: a2a3 a4a5 a6a7 a8a9 aaab acad aeaf b0b1 ................
0x00c0: b2b3 b4b5 b6b7 b8b9 babb bcbd bebf c0c1 ................
0x00d0: c2c3 c4c5 c6c7 c8c9 cacb cccd cecf d0d1 ................
0x00e0: d2d3 d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 ................
0x00f0: e2e3 e4e5 e6e7 e8e9 eaeb eced eeef f0f1 ................
0x0100: f2f3 f4f5 f6f7 f8f9 fafb fcfd feff 0001 ................
0x0110: 0203 0405 0607 0809 0a0b 0c0d 0e0f 1011 ................
0x0120: 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 ...............!
0x0130: 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 "#$%&'()*+,-./01
0x0140: 3233 3435 3637 3839 3a3b 3c3d 3e3f 4041 23456789:;<=>?@A
0x0150: 4243 4445 4647 4849 4a4b 4c4d 4e4f 5051 BCDEFGHIJKLMNOPQ
0x0160: 5253 5455 5657 5859 5a5b 5c5d 5e5f 6061 RSTUVWXYZ[\]^_`a
0x0170: 6263 6465 6667 6869 6a6b 6c6d 6e6f 7071 bcdefghijklmnopq
0x0180: 7273 7475 7677 7879 7a7b 7c7d 7e7f 8081 rstuvwxyz{|}~...
(etc.)
If I remove the "scrub" pf feature: There is no more problem.
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-pf
mailing list