PF Firewall on OSX with IceFloor

Question

I have set up pf using IceFloor on my OSX 10.9 system running Server 3.0.2. Everything seems to be fine except that I can not connect to the system using the DNS name or the public IP from localhost. E.g. I can connect to http/port 80 from the internet, but not from the machine itself using the public IP. The connection from the machine to localhost/127.0.0.1 works. Here is the log I get (x.x.x.x is the public IP of the host):

rule 7/0(match): block in on en0: x.x.x.x.80 > x.x.x.x.64460: Flags [R.], seq 1, ack 1, win 65535, length 0

And here is the list of rules

$ sudo pfctl -s rules
[sudo] password for paul: 
No ALTQ support in kernel
ALTQ related functions disabled
scrub-anchor "icefloor.nat" all fragment reassemble
anchor "icefloor.nat" all
block drop in quick from <emergingthreats> to any
block drop out quick from any to <emergingthreats>
block drop in log quick from <_blacklist> to any
block drop out log quick from any to <_blacklist>
block drop in quick from no-route to any
block drop in quick from urpf-failed to any label "uRPF"
block drop log inet all label "Generic_blocks_(IPv4)"
block drop log inet6 all label "Generic_blocks_(IPv6)"
anchor "icefloor.groupblocks" all label "Blocks"
anchor "inspector.blocks" all label "Temp_blocks"
anchor "icefloor.exceptions" all label "Logs_exceptions"
anchor "icefloor.portknocking" all label "Hidden_services"
anchor "icefloor.genericipv6" all
anchor "icefloor.inbound" all label "Local_services"
anchor "icefloor.outbound" all label "All_traffic"
anchor "icefloor.outbound_nat" all label "NAT_clients_traffic"
anchor "icefloor.custom_rules" all

Can you tell me which one the rule 7/0(match) is? And why it is not allowed to connect from localhost to the public key (on any open ports)? Has it something to do with the no-route f rule? Or the two Generic_blocks_-rules?

Thanks in advance,

Paul

Answer 1

I too was facing this issue and it took quiet a bit of testing and tcpdump to figure it all out.

To answer your first question, which one the rule 7/0(match) is: It is the "Generic_blocks_(IPv4)" rule automatically added by IceFloor to block and log all non-explicitly authorized traffic. You can confirm that rule's number by running pfctl -gsr as root.

On to the reason why it is blocked. The inbound connection is what is blocked. It has nothing to do with the no-route or anything in the visible ruleset. It has to do with how your DNS name is handled locally. Your machine's routing table (netstat -r) has an entry for your DNS name that points to localhost on the lo0 interface.

The log entry contains some puzzling information, specifically the block in on en0, which leads you to believe something is happening on interface en0. However, doing a tcpdump -nvvvi en0 tcp and port 80 showed that no packets were actually traveling on en0. Packets were, however, found with tcpdump -nvvvi lo0 tcp and port 80, thus confirming that the traffic was (as expected) happening on lo0.

The default IceFloor configuration (/Library/IceFloor/icefloor.conf) is generated with a line that has set skip on lo0. At first, this seems like a very standard, welcomed line (see http://www.openbsd.org/faq/pf/options.html). Every other piece of lo0 appeared unhindered by the pf rules. On a hunch, I decided to comment out that line and add a new rule (just after the table include): pass quick on lo0. After reloading with this modified configuration, I was successfully able to access my web server via my DNS name (problem solved). So it looks like the set skip on lo0 line has some issues.

The setback with manually modifying the icefloor.conf file is that it then prevents you from using the Firewall tab in the IceFloor interface. As saving a new configuration would override any manual edits.