pkg slow down a lot with simple firewall.

Thu May 28 01:20:25 UTC 2020

Thank you Doug and Cristian for all your help.

I found the solution based on something Doug said about seeing a request in IPv6.  I decided to try something I found in Absolute Freebsd pg 356.  

"I've been on more than one network that has better IPv6 connectivity than IPv4, or the other way.  Direct pkg to use one network protocol or the other with the IP_VERSION setting in pkg.conf.  You can set this to 4, 6 or let the host autoselect with the default of 0."

When I set it to 4, my problem disappeared.

Thank you Cristian for the site.  I will make good use of it.
Regards,
Don Mickunas

On Wed, May 27, 2020, at 20:36, Cristian Cardoso wrote:
> 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=pf.conf&sektion=5&n=1
> 
> Em qua., 27 de mai. de 2020 às 19:18, Doug Hardie <bc979 at lafn.org> escreveu:
> >
> > > On 27 May 2020, at 14:38, Donald Mickunas <dmickunas1954 at 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 > 192.168.1.1.53: 18844+[|domain]
> > > 00:00:00.049750 rule 7/0(match): pass out on em0: 192.168.1.4.48855 > 192.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 > 192.168.1.1.53: 49030+[|domain]
> > > 00:00:00.442261 rule 7/0(match): pass out on em0: 192.168.1.4.12228 > 192.168.1.1.53: 15101+[|domain]
> > > 00:00:00.105498 rule 7/0(match): pass out on em0: 192.168.1.4.31652 > 192.168.1.1.53: 56618+[|domain]
> > > 00:00:00.136933 rule 3/0(match): pass out on em0: 2600:6c5c:6000:32a0:1a03: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 > 96.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 > 192.168.1.1.53: 30468+[|domain]
> > > 00:00:00.000800 rule 7/0(match): pass out on em0: 192.168.1.4.27145 > 192.168.1.1.53: 3978+[|domain]
> > > 00:00:00.000739 rule 3/0(match): pass out on em0: 2600:6c5c:6000:32a0:1a03: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 > 96.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 > 192.168.1.1.53: 2366+[|domain]
> > > 00:00:00.000531 rule 7/0(match): pass out on em0: 192.168.1.4.65475 > 192.168.1.1.53: 41713+[|domain]
> > > 00:00:00.000772 rule 3/0(match): pass out on em0: 2600:6c5c:6000:32a0:1a03: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 > 96.47.72.71.80: Flags [S], seq 222404333, win 65535, options [mss 1460,nop,wscale 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 switches to IPv6.  It also only shows the output packets so delays caused at the server end cannot be distinguished.  I would recommend using tcpdump to 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 find it in the output of ifconfig.  It will be the interface that has your IP address in it. For example, mine is:
> >
> > bge0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
> >         options=c019b<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=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
> >
> > and the interface name is bge0.
> >
> > Then in the second window start the pkg update command.  Note, tcpdump will produce a lot of output.  The output will have a time stamp (hours:minutes: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
>