PF SSH pauses and freezes with PF enabled

B

bufo333

I have a server running PF to protect its local services. I have noticed that with PF enabled the ssh session will freeze for several minutes before becoming responsive again. This only happens when I cat a large file, or do anything that generates a large amount of text output. If I disable PF SSH works without problems. I have tried to enable and disabling the scrub feature but it has no effect on the problem.

I am running 10.1-RELEASE-p5

Rule base attached below:

Code: 
set skip on lo0
set skip on lo1
set skip on lo2
#scrub in all no-df max-mss 1440
block in
block in log quick proto tcp flags FUP/WEUAPRSF
block in log quick proto tcp flags WEUAPRSF/WEUAPRSF
block in log quick proto tcp flags SRAFU/WEUAPRSF
block in log quick proto tcp flags /WEUAPRSF
block in log quick proto tcp flags SR/SR
block in log quick proto tcp flags SF/SF
pass out quick on xn0 proto tcp from any to any keep state
pass out quick on xn0 proto udp from any to any
pass out quick on xn0 proto icmp from any to any
pass in quick on xn0 proto icmp from any to any
pass in quick on xn0 proto tcp from any to 172.x.x.x port 22 keep state
pass in quick on xn0 proto tcp from any to 172.x.x.x port 64738 keep state
pass in quick on xn0 proto udp from any to 172.x.x.x port 64738

Code: 
ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
        inet 127.0.0.1 netmask 0xff000000
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
xn0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=503<RXCSUM,TXCSUM,TSO4,LRO>
        ether 12:20:20:7c:da:b6
        inet 172.x.x.x netmask 0xffffff00 broadcast 172.x.x.255
        inet 172.x.x.x netmask 0xffffff00 broadcast 172.x.x.255
        inet 172.x.x.x netmask 0xffffff00 broadcast 172.x.x.255
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet manual
        status: active
lo1: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
        inet 127.0.1.1 netmask 0xffffffff
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
lo2: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
        inet 127.0.1.2 netmask 0xffffffff
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
 
But there is for all tcp sessions...
I suspect you're seeing bandwidth congestion in one direction, is this an asymmetric connection?
//Danne
 
diizzy said:
But there is for all tcp sessions...
I suspect you're seeing bandwidth congestion in one direction, is this an asymmetric connection?
//Danne
Click to expand...

It is a VPC on Amazon EC2, however I can duplicate the issue on an ESX VM in house. I definitely think its something with my config. I did a packet capture and I am seeing 60 second delays to response packets only when they are larger than 500kb usually 1440kb for a full screen of text. The problem goes away if I disable PF with pfctl -d
 
Comment out all block in ..flags.. and add an interface on the first "block in" line
Does that help?
//Danne
 
Last edited:
diizzy said:
Comment out all black in ..flags.. and add an interface on the first "block in" line
Does that help?
//Danne
Click to expand...

Thanks for the help
It seems that changing
Code: 
block in all
to
Code: 
block all
Seems to have resolved the issue. Amazing, I wonder why the difference?
 
bufo333, to see what gets blocked by your current firewall ruleset you should enable logging like shown in the FreeBSD Handbook pf section: https://www.freebsd.org/doc/en/books/handbook/firewalls-pf.html and add the following to your /etc/rc.conf.
Code: 
pflog_enable="YES"
an change your "block all" line in /etc/pf.conf to:
Code: 
block log all
Reload your ruleset with pfctl -n -f /etc/pf.conf && pfctl -F rules -f /etc/pf.confand watch the blocked packets with something like:
tcpdump -i pflog0 -nn
Maybe this gives some insight.
 
You must log in or register to reply here.
Back
Top