PfSense not blocking entered ip addresses

battles

I have tried to block the ip 40.77.226.249 in the pfSense firewall, but as you can see, my computer is still making connections. I have entries the ip in both the the firewall directly and in a blocklist. Can someone tell me why pfSense isn't blocking it?

wireshark records:

730 Sep 22, 2016 10:06:53.366949000 CDT 192.168.1.100 40.77.226.249 50077 → 443 [SYN] Seq=0 Win=8192…
731 Sep 22, 2016 10:06:53.502780000 CDT 40.77.226.249 192.168.1.100 443 → 50077 [SYN, ACK] Seq=0 Ack=1…
732 Sep 22, 2016 10:06:53.502859000 CDT 192.168.1.100 40.77.226.249 50077 → 443 [ACK] Seq=1 Ack=1…
733 Sep 22, 2016 10:06:53.503209000 CDT 192.168.1.100 40.77.226.249 Client Hello

firewall.png_thumb

johnpoz

Well your rules are completely wrong would be why ;)

If your wanting a lan box from creating a connection then the rules need to be on int where pfsense would first see that traffic. Ie the lan interface. And it needs to be before any allow that would allow that traffic.

So for example in your lan going top down first rule wins, your any any allows the traffic - it never sees your block. And then even if it did see your block the source sure is not the IP your trying to go to.. It wold be the IP of the box in your lan your trying to stop, or just lan never if you want to block everyone in lan.

So correct your rule on lan for correct source, then move it to above your allow any any.
Delete your wan rule - completely pointless. Wan rules are for allowing traffic in, or blocking someone from using a specific forward you have setup. Wan is default deny.. Unless something is answering a connection you created..

Once you have correct your lan rules, clear any states that might already exist.

BTW your passlist and block rules are completely pointless as well on the lan since they are below your any any rule. As to them on the wan also pointless. You don't have any forwards so when would they come into play? your pass list would allow stuff to hit your pfsense wan ports that are open. But block is useless for sure. And do you really want any any from those IPs to your wan IP. Why would you not just open up the specific ports you want to allow to your wan. Maybe icmp, vpn maybe.. Other than that can not see any reason to allow anything to the wan. If you need to admin your pfsense while your remote you should vpn into it.

Rules are processed TOP down, first rule to fire wins - no other rules will be looked at.

battles

Thanks. I am used to using iptables and find its top down form to be easy to follow. I'll study your explanation and work from there. I think that separate WAN and LAN configurations are confusing me.

KOM

I am used to using iptables and find its top down form to be easy to follow.

pfSense works top-down, first-match for all rules except floating rules which are top-down, last-match. Rules must be placed on the interface that the traffic enters, as John said. LAN traffic from clients goes IN the LAN and then OUT the WAN. Reply traffic from the Internet comes IN the WAN and OUT the LAN to the LAN client.

johnpoz

pfsense is top down as well. And you set rules on specific interfaces in iptables as well. I don't see how they are really any different.

Have had this discussion before, I don't get why it seems confusing for new users. If your going to write a firewall rule where would you write it. You would want to evaluate it on where it would be first seen to the firewall. So the ingress interface..

The firewall basics doc clearly states
"Firewall rules on Interface and Group tabs process traffic in the Inbound direction and are processed from the top down, stopping at the first match. Where no user-configured firewall rules match, traffic is denied. "

Maybe we need a pretty picture to help? ;)

kpa

Do note that all of the PF documentation (such as the OpenBSD PF FAQ) keeps talking about "last matching rule wins". The PF implementation in pfSense hasn't changed this but all of the user rules use the "quick" keyword that short circuits the rule evaluation making pfSense essentially a "first matching rule wins" system.

johnpoz

While you have a valid point if you do not use the quick keyword it would be last rule to match wins. Their faq seems to make that very clear that if quick is used its first rule wins

"Filter rules specify the criteria that a packet must match and the resulting action, either block or pass, that is taken when a match is found. Filter rules are evaluated in sequential order, first to last. Unless the packet matches a rule containing the quick keyword, the packet will be evaluated against all filter rules before the final action is taken."

But this makes a valid point that the firewall basic doc should be updated to reflect that rules created on interface tabs use the quick keyword. When I get a chance I will do that, and add a pretty picture as well ;) Unless someone beats me too it.

attilahooper

I know this is an old thread, but it helped me shut down my kid's iphone who's incessantly snapchatting.
I had the right rules targeting the device IP in the floating group with quick checked, but no joy. Then johnpoz noted

Once you have correct your lan rules, clear any states that might already exist.

Ahah! diagnostics|states|reset states(reset firewall state table) and bingo, daughter called me in the man-cave and hung up, she must be pissed.

Pretty interesting, a new rule will not interrupt an existing connection.