Seems to be a BUG in pf with FreeBSD 10?

I

ikevin8me

This is either a bug in FreeBSD 10 with the pf firewall, or things have changed so drastically that I cannot figure out how to make it work correctly.

After a fresh, clean install of FreeBSD 10, I would set up my SSH to listen on a high port (say, 30000) and activate it by service sshd onestart. Then, I would set the pf firewall to block out all traffic, except for sshd. The pf settings would look something like this:
Code: 
set skip on lo
pass in quick on [INTERFACE] inet proto tcp from any to <LISTENING SERVER IP ADDRESS> port 30000 
block drop log all

In addition, I also tried a variation of settings for sshd to listen on the standard port 22, but redirect it from the firewall:
Code: 
set skip on lo
rdr on [INTERFACE] proto tcp from any to <LISTENING SERVER IP ADDRESS> port 30000 -> 127.0.0.1 port 22
block drop log all
pass in inet proto tcp to 127.0.0.1 port 22

I would first activate the pf firewall by issuing the command service pf onestart. At this point, everything worked correctly. I could ssh into the machine remotely and it also stops responding to ICMP pings (since it is not allowed in the firewall rules). By disabling it by service pf stop, everything reverted just as expected (i.e. including ICMP pings responded). I even tried a few times and things worked as expected.

The problem happens when I enable it within /etc/rc.conf by inserting
Code: 
sshd_enable="YES"
pf_enable="YES"
and a reboot. After the reboot, the machine simply refuses to accept the SSH connection (which it did by the service pf onestart testing with exactly the same unchanged firewall rules). I even tried to disable the firewall by service pf stop and pfctl -d. Nothing worked. It still continues to refuse the SSH connections and pings won't respond. It is like a complete firewall permanently glued to it and there's no way to disable it. I tried the command pfctl -sr and saw the rules are no longer there BUT connections still won't work and pings won't respond. It is just like superficially it shows disabled but the firewall blockage is still active.

The only way to disable the firewall is to log in by console and mark out
Code: 
#enable_pf="YES"
in rc.conf file, and then reboot.

NOTE: it is a fresh, clean install of FreeBSD 10. I have not done anything else including changing the security level, or that sort of things. Further, I have re-installed the OS again and repeated all the same steps with the same result.
 
There must be something wrong in your configurations, because on my machine ( FreeBSD 10.0-RELEASE ) sshd and pf in rc.conf work as they should.
 
Now, keep in mind that I don't use FreeBSD 10 as of yet. Having that out of the way I can't help wonder if you also checked if sshd was actually listening to the port you specified?

So basically; if you start both pf and sshd through /etc/rc.conf does # sockstat -4lp 30000 show anything?
 
CoTones said:
It must be something wrong in your configurations, because on my machine ( FreeBSD 10.0-RELEASE ) sshd and pf in rc.conf works as it should.
Click to expand...

It is very strange. Mine doesn't.
 
ShelLuser said:
So basically; if you start both pf and sshd through /etc/rc.conf does # sockstat -4lp 30000 show anything?
Click to expand...

Yes, sshd is indeed listening. Though I cannot access it via ssh remotely, I could still login via the console and then ssh 127.0.0.1 or ssh <SERVER IP ADDRESS> and sshd indeed responds. So, that means there is really nothing wrong with sshd.
 
I went one more step to verify the problem. I simplified my /etc/pf.conf to just:
Code: 
set skip on lo
block drop log all

With just the rule above (only two lines), it would reject ICMP pings if activated, or respond to ICMP pings if deactivated. Simple tests.

First test: I rebooted the machine with
Code: 
#pf_enable="YES"
(i.e., turned off). I then started my ping. After the machine is booted up, it responds with ping. I then login via the console to play with service pf onestart and the pings stops responding, and giving another command service pf stop would make the pings come back. I did this repeatedly a few times. So far so good. The behavior is very normal and correct.

Second test: I removed the # so it becomes
Code: 
pf_enable="YES"
(i.e., turned on) and rebooted the machine. After the machine gets booted up, pings do not reply. This is correct since the firewall ruleset prevents the responds. Then, I log in via the console and try to disable pf by service pf stop and pfctl -d. None worked, that is, the pings never came back. It is like the firewall can never be disabled.

NOTE: from first test to the second test, I did nothing except by removing the # in
Code: 
pf_enable="YES"

Could we get the FreeBSD developers to look into the service pf start loading sequence and where it is reading the configuration file? Then, why is it that trying to disable pf does not work at all? Clearly, something is wrong.
 
I have made another discovery.

I set my /etc/pf.conf to:

Code: 
set skip on lo
pass in quick on [INTERFACE] inet proto tcp from any to <LISTENING SERVER IP ADDRESS> port 30000 
block drop log all

and my /etc/rc.conf to include:
Code: 
pf_enable="YES"
sshd_enable="YES"

and of course, setting sshd to listen on port 30000 and testing it.

I rebooted the machine. It didn't work (remote SSH did not respond), which is expected due to the problem reported here. I logged in via console and turned off pf by executing service pf stop. I then tried ping to the remote machine. With the firewall turned off, ping should work, but it didn't. Then, miraculously, from inside the machine, I did a dig google.com. It displayed Google's IP addresses. At the same time, the remote ping worked, i.e. it responded. I restarted the machine and tested again exactly the same way. The results were the same. It seems that the network was not activated until the dig google.com was executed. I don't understand this behavior. (I have re-installed the OS again for this testing.)
 
Troubleshooting can surely be frustrating when you poke at this and poke at that without really being able to see what is going on. My suggestion is that you pull some tcpdumps on your interfaces so you can really see what is being put on the wire. Armed with that information, I promise, you will be better informed.

Good luck.
 
That could possible be the culprit. That problem is reproduceable on both FreeBSD 9.2 and 10. I just don't have time to write a report, but will consider doing so if I have time.
 
You must log in or register to reply here.
Back
Top