#Icefloor machine manual
As saving a new configuration would override any manual edits.You are looking at a Scotsman C1848 Prodigy Ice Machine capable of producing up to 1,909 lbs of ice per day!! This unit was used for 3 months and in almost prestine condition. The setback with manually modifying the nf file is that it then prevents you from using the Firewall tab in the IceFloor interface. So it looks like the set skip on lo0 line has some issues. After reloading with this modified configuration, I was successfully able to access my web server via my DNS name (problem solved).
On a hunch, I decided to comment out that line and add a new rule (just after the table include): pass quick on lo0.
Every other piece of lo0 appeared unhindered by the pf rules. At first, this seems like a very standard, welcomed line (see ). The default IceFloor configuration ( /Library/IceFloor/nf) is generated with a line that has set skip on lo0. Packets were, however, found with tcpdump -nvvvi lo0 tcp and port 80, thus confirming that the traffic was (as expected) happening on lo0. However, doing a tcpdump -nvvvi en0 tcp and port 80 showed that no packets were actually traveling on en0. The log entry contains some puzzling information, specifically the block in on en0, which leads you to believe something is happening on interface en0. Your machine's routing table ( netstat -r) has an entry for your DNS name that points to localhost on the lo0 interface. It has to do with how your DNS name is handled locally. It has nothing to do with the no-route or anything in the visible ruleset. The inbound connection is what is blocked. You can confirm that rule's number by running pfctl -gsr as root. 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. I too was facing this issue and it took quiet a bit of testing and tcpdump to figure it all out. Scrub-anchor "icefloor.nat" all fragment reassembleīlock drop in quick from urpf-failed to any label "uRPF"īlock drop log inet all label "Generic_blocks_(IPv4)"īlock drop log inet6 all label "Generic_blocks_(IPv6)"Īnchor "oupblocks" all label "Blocks"Īnchor "inspector.blocks" all label "Temp_blocks"Īnchor "icefloor.exceptions" all label "Logs_exceptions"Īnchor "icefloor.portknocking" all label "Hidden_services"Īnchor "icefloor.inbound" all label "Local_services"Īnchor "icefloor.outbound" all label "All_traffic"Īnchor "icefloor.outbound_nat" all label "NAT_clients_traffic"Ĭan 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? 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, seq 1, ack 1, win 65535, length 0Īnd here is the list of rules $ sudo pfctl -s rules The connection from the machine to localhost/127.0.0.1 works. I can connect to http/port 80 from the internet, but not from the machine itself using the public IP. Everything seems to be fine except that I can not connect to the system using the DNS name or the public IP from localhost. I have set up pf using IceFloor on my OSX 10.9 system running Server 3.0.2.
0 kommentar(er)
