PF a NAT pro lokalni sit / MTU

Miroslav Lachman 000.fbsd at quip.cz
Sat Mar 23 00:54:37 CET 2019


Dan Lukes wrote on 2019/03/22 14:11:
> On 22.3.2019 13:03, Miroslav Lachman wrote:

> Ono by se samozrejem i bez dumpu daly rozvijet nejruznejsi hypotezy - 
> ale proc hadat, kdyz je mozne videt ...
> 
> Jura ma stejne podezreni - velikost paketu. Tak jestli ti to jako 
> hypoteza staci, tak dump nepotrebujes ;-)
> 
>> Ale tady me nejvic zarazi, ze to tak nejak napul funguje.
> 
> To bys prave dobre videl v tom dumpu ;-)

Do toho tcpdumpu jsem ted koukal pomerne dlouho, ale mam pocit, ze do 
toho cumim jak husa do flasky.

Takhle to vypada, kdyz zkusim telnet na port 80, pak zadat GET / 
HTTP/1.0, dvakrat ENTER a na treti ENTER dojde k disconnectu.
tcpdump jsem porizovat na vnejsi sitovce (bge0) a telnet jsem delal ze 
stanice v LAN (LAN je na bge1)

22:17:03.129676 IP AA.BB.CC.DD.50181 > WW.XX.YY.ZZ.80: Flags [S], seq 
779984406, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 
93959379 ecr 0], length 0
22:17:05.634234 IP WW.XX.YY.ZZ.80 > AA.BB.CC.DD.50181: Flags [S.], seq 
895119811, ack 779984407, win 65535, options [mss 1460,nop,wscale 
6,sackOK,TS val 75267056 ecr 93959379], length 0
22:17:05.634611 IP AA.BB.CC.DD.50181 > WW.XX.YY.ZZ.80: Flags [.], ack 1, 
win 1040, options [nop,nop,TS val 93961884 ecr 75267056], length 0
22:17:08.641792 IP WW.XX.YY.ZZ.80 > AA.BB.CC.DD.50181: Flags [S.], seq 
895119811, ack 779984407, win 65535, options [mss 1460,nop,wscale 
6,sackOK,TS val 75267056 ecr 93959379], length 0
22:17:08.642325 IP AA.BB.CC.DD.50181 > WW.XX.YY.ZZ.80: Flags [.], ack 1, 
win 1040, options [nop,nop,TS val 93964891 ecr 75267056], length 0
22:17:08.650351 IP WW.XX.YY.ZZ.80 > AA.BB.CC.DD.50181: Flags [.], ack 1, 
win 2053, options [nop,nop,TS val 75270072 ecr 93961884], length 0
22:17:09.038862 IP AA.BB.CC.DD.50181 > WW.XX.YY.ZZ.80: Flags [P.], seq 
1:17, ack 1, win 1040, options [nop,nop,TS val 93965288 ecr 75270072], 
length 16: HTTP: GET / HTTP/1.0
22:17:10.982234 IP WW.XX.YY.ZZ.80 > AA.BB.CC.DD.50181: Flags [.], ack 
17, win 2053, options [nop,nop,TS val 75272404 ecr 93965288], length 0
22:17:10.982609 IP AA.BB.CC.DD.50181 > WW.XX.YY.ZZ.80: Flags [P.], seq 
17:19, ack 1, win 1040, options [nop,nop,TS val 93967232 ecr 75272404], 
length 2: HTTP
22:17:11.182130 IP WW.XX.YY.ZZ.80 > AA.BB.CC.DD.50181: Flags [F.], seq 
846, ack 19, win 2053, options [nop,nop,TS val 75272603 ecr 93967232], 
length 0
22:17:11.182494 IP AA.BB.CC.DD.50181 > WW.XX.YY.ZZ.80: Flags [.], ack 1, 
win 1040, options [nop,nop,TS val 93967432 ecr 75272404], length 0
22:17:12.382706 IP AA.BB.CC.DD.50181 > WW.XX.YY.ZZ.80: Flags [P.], seq 
19:21, ack 1, win 1040, options [nop,nop,TS val 93968632 ecr 75272404], 
length 2: HTTP
22:17:12.699281 IP WW.XX.YY.ZZ.80 > AA.BB.CC.DD.50181: Flags [R], seq 
895119812, win 0, length 0


Zkusil jsem minimalizovat pravidla firewallu na tohle

# pfctl -s all
TRANSLATION RULES:
nat pass on bge0 inet from 192.168.1.0/24 to any -> (bge0) round-robin

FILTER RULES:
pass on bge1 all flags S/SA keep state
pass on bge0 all flags S/SA keep state

Ale porad stejny vysledek.

Tak jsem zkusil Jirkuv tip na velikost packetu... a maximalni velikost, 
kterou jsem z toho stroje schopen pingat, je 552. Na 553 uz mi neprijde 
odpoved.

# ping -s 552 www.freebsd.cz
PING www.freebsd.cz (195.113.15.29): 552 data bytes
560 bytes from 195.113.15.29: icmp_seq=0 ttl=53 time=9.517 ms
560 bytes from 195.113.15.29: icmp_seq=1 ttl=53 time=8.682 ms


# tcpdump -i bge0 -n host www.freebsd.cz
23:14:30.332097 IP AA.BB.CC.DD > 195.113.15.29: ICMP echo request, id 
13913, seq 0, length 552
23:14:30.332103 IP AA.BB.CC.DD > 195.113.15.29: ip-proto-1
23:14:30.341185 IP 195.113.15.29 > AA.BB.CC.DD: ICMP echo reply, id 
13913, seq 0, length 560
23:14:31.336724 IP AA.BB.CC.DD > 195.113.15.29: ICMP echo request, id 
13913, seq 1, length 552
23:14:31.336729 IP AA.BB.CC.DD > 195.113.15.29: ip-proto-1
23:14:31.345047 IP 195.113.15.29 > AA.BB.CC.DD: ICMP echo reply, id 
13913, seq 1, length 560



Packety, ktere jsou 553 a vetsi neprojdou

# ping -s 553 www.freebsd.cz 

PING www.freebsd.cz (195.113.15.29): 553 data bytes
^C
--- www.freebsd.cz ping statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss

# tcpdump -i bge0 -n host www.freebsd.cz
23:14:41.204070 IP AA.BB.CC.DD > 195.113.15.29: ICMP echo request, id 
18765, seq 0, length 552
23:14:41.204076 IP AA.BB.CC.DD > 195.113.15.29: ip-proto-1
23:14:42.206609 IP AA.BB.CC.DD > 195.113.15.29: ICMP echo request, id 
18765, seq 1, length 552
23:14:42.206615 IP AA.BB.CC.DD > 195.113.15.29: ip-proto-1


A ted mi nekdo reknete, cim to muze byt?

Mam tu vedle sebe ty dva stroje, stary a novy. Zapojeni vseho okolo 
zustava stejne, jenom z noveho prepojim 2 UTP kabely zpatky do stareho a 
razem muzu pingat az do velikosti 1472.

Ping ze stanice v LAN, kdyz je zapojeny stary "router".

# ping -s 1472 www.freebsd.cz 

PING www.freebsd.cz (195.113.15.29): 1472 data bytes
1480 bytes from 195.113.15.29: icmp_seq=0 ttl=53 time=9.550 ms
1480 bytes from 195.113.15.29: icmp_seq=1 ttl=53 time=9.473 ms
^C
--- www.freebsd.cz ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 9.473/9.512/9.550/0.038 ms


Zkousel jsem ifconfigem vypinat ruzne featury na sitovkach, jako je TSO, 
ale k nicemu to nevedlo a vazne me nenapada, proc by uplne normalni 
instalace FreeBSD 11.2 mela mit problem s packety nad 552b.

ifconfig na bge0 hlasi mtu 576 (ale proc?)

bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 576
options=c019b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE>
         nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
         media: Ethernet autoselect (1000baseT <full-duplex>)
         status: active
bge1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=c019b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE>

Takze jsem zase vratil zpatky stary stroj a jsem zase na zacatku.

Kazdopadne specialni dik pro Jirku, protoze me by asi vazne nenapadlo 
hledat problem ve velikosti packetu / MTU.

A vlastne jeste jedna zajimavost - na tom novem stroji jsem nainstaloval 
elinks a tim se dostanu treba na http://yahoo.com/ - ze stanice v LAN ne.

Mirek

PS: na starem stroji hlasi ifconfig mtu 1500, pokud je zapojen do toho 
sameho UPC modemu, kde predtim byl novy stroj a ten mel mtu 576

xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
         options=1<RXCSUM>


More information about the Users-l mailing list