Date: Wed, 27 May 2020 21:36:19 -0300 From: Cristian Cardoso <cristian.cardoso11@gmail.com> To: Doug Hardie <bc979@lafn.org> Cc: Donald Mickunas <dmickunas1954@fastmail.com>, FreeBSD PF List <freebsd-pf@freebsd.org> Subject: Re: pkg slow down a lot with simple firewall. Message-ID: <CAKeEC-JrvWFWcLqg1D6EuE-3Bvscxox8fw_e=C76KeG=NpdH5A@mail.gmail.com> In-Reply-To: <E1A56113-CB15-40EF-A398-2DCE4EF900AF@mail.sermon-archive.info> References: <804eeda4-03ed-4ec8-8755-3130e06382d8@www.fastmail.com> <CAKeEC-L1PTNU4Wr09rspFf7xkn1zE_%2BhghM7k6j9%2BbaZ3ObT-g@mail.gmail.com> <8347b16b-5b9b-4e62-88fc-a3f19dc138a8@www.fastmail.com> <0E48F161-081E-43F8-B00D-9888A48D7AA2@mail.sermon-archive.info> <51ae9da1-ccbb-4a1c-b1e3-155bce912cc5@www.fastmail.com> <E1A56113-CB15-40EF-A398-2DCE4EF900AF@mail.sermon-archive.info>
next in thread | previous in thread | raw e-mail | index | archive | help
I reinforce Doug's recommendation and if you want to log the things that are possibly blocked, insert it in pf.conf block in log all About what Doug talked about starting the connection in IPv4 and switching to IPv6, it is only the DNS request in IPv4 that is managing to answer the domain update.freebsd.org in IPv6, with that the pkg requests come out via IPv6 One thing that helped me a lot in the beginning was this URL: https://www.freebsd.org/cgi/man.cgi?query=3Dpf.conf&sektion=3D5&n=3D1 Em qua., 27 de mai. de 2020 =C3=A0s 19:18, Doug Hardie <bc979@lafn.org> esc= reveu: > > > On 27 May 2020, at 14:38, Donald Mickunas <dmickunas1954@fastmail.com> = wrote: > > > > Thanks, Doug. > > > > Here are the results after running pkg update once. > > > > $ sudo tcpdump -n -e -ttt -r /var/log/pflog > > Password: > > reading from file /var/log/pflog, link-type PFLOG (OpenBSD pflog file) > > 00:00:00.000000 rule 7/0(match): pass out on em0: 192.168.1.4.25334 > 1= 92.168.1.1.53: 18844+[|domain] > > 00:00:00.049750 rule 7/0(match): pass out on em0: 192.168.1.4.48855 > 1= 92.168.1.1.53: 59873+[|domain] > > 00:00:00.049459 rule 9/0(match): pass out on em0: 192.168.1.4.123 > 209= .94.190.139.123: NTPv4, Client, length 48 > > 00:00:00.887723 rule 9/0(match): pass out on em0: 192.168.1.4.123 > 64.= 6.144.6.123: NTPv4, Client, length 48 > > 00:00:29.345987 rule 7/0(match): pass out on em0: 192.168.1.4.51718 > 1= 92.168.1.1.53: 49030+[|domain] > > 00:00:00.442261 rule 7/0(match): pass out on em0: 192.168.1.4.12228 > 1= 92.168.1.1.53: 15101+[|domain] > > 00:00:00.105498 rule 7/0(match): pass out on em0: 192.168.1.4.31652 > 1= 92.168.1.1.53: 56618+[|domain] > > 00:00:00.136933 rule 3/0(match): pass out on em0: 2600:6c5c:6000:32a0:1= a03:73ff:fe3a:d596.60802 > 2610:1c1:1:606c::50:1.80: [|tcp] > > 00:00:34.523685 rule 9/0(match): pass out on em0: 192.168.1.4.123 > 74.= 6.168.73.123: NTPv4, Client, length 48 > > 00:00:00.526029 rule 3/0(match): pass out on em0: 192.168.1.4.12913 > 9= 6.47.72.71.80: Flags [S], seq 1540288966, win 65535, options [mss 1460,nop,= wscale 6,sackOK,TS[|tcp]> > > 00:00:00.075191 rule 7/0(match): pass out on em0: 192.168.1.4.11403 > 1= 92.168.1.1.53: 30468+[|domain] > > 00:00:00.000800 rule 7/0(match): pass out on em0: 192.168.1.4.27145 > 1= 92.168.1.1.53: 3978+[|domain] > > 00:00:00.000739 rule 3/0(match): pass out on em0: 2600:6c5c:6000:32a0:1= a03:73ff:fe3a:d596.64864 > 2610:1c1:1:606c::50:1.80: [|tcp] > > 00:00:18.977520 rule 3/0(match): pass out on em0: 192.168.1.4.58497 > 9= 6.47.72.71.80: Flags [S], seq 2776579475, win 65535, options [mss 1460,nop,= wscale 6,sackOK,TS[|tcp]> > > 00:00:00.082616 rule 7/0(match): pass out on em0: 192.168.1.4.15248 > 1= 92.168.1.1.53: 2366+[|domain] > > 00:00:00.000531 rule 7/0(match): pass out on em0: 192.168.1.4.65475 > 1= 92.168.1.1.53: 41713+[|domain] > > 00:00:00.000772 rule 3/0(match): pass out on em0: 2600:6c5c:6000:32a0:1= a03:73ff:fe3a:d596.55684 > 2610:1c1:1:606c::50:1.80: [|tcp] > > 00:00:18.883826 rule 3/0(match): pass out on em0: 192.168.1.4.25039 > 9= 6.47.72.71.80: Flags [S], seq 222404333, win 65535, options [mss 1460,nop,w= scale 6,sackOK,TS[|tcp]> > > $ > > > > I have no idea how to interpret this. Any help would be appreciated. > > That is quite unexpected. The connection starts out with IPv4 and then s= witches to IPv6. It also only shows the output packets so delays caused at= the server end cannot be distinguished. I would recommend using tcpdump t= o see the entire transaction. > > In one window, start tcpdump with: > tcpdump -ixxx -ttt -s0 -X port 80 > > Here you need to replace xxx above with your interface name. You can fin= d it in the output of ifconfig. It will be the interface that has your IP = address in it. For example, mine is: > > bge0: flags=3D8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric= 0 mtu 1500 > options=3Dc019b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM= ,TSO4,VLAN_HWTSO,LINKSTATE> > ether 38:c9:86:07:3b:5b > inet 10.0.1.250 netmask 0xffffff00 broadcast 10.0.1.255 > inet6 fe80::3ac9:86ff:fe07:3b5b%bge0 prefixlen 64 scopeid 0x1 > inet6 fee1::250 prefixlen 64 > media: Ethernet autoselect (100baseTX <full-duplex>) > status: active > nd6 options=3D23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL> > > and the interface name is bge0. > > Then in the second window start the pkg update command. Note, tcpdump wi= ll produce a lot of output. The output will have a time stamp (hours:minut= es:seconds.microseconds). It will be a delta time from the previous packet= . Look for one where the seconds are greater than zero. That is where the= delays are occurring. > > -- Doug
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAKeEC-JrvWFWcLqg1D6EuE-3Bvscxox8fw_e=C76KeG=NpdH5A>