Outbound traffic not blocked
-
" I also have that rule on the WAN side, but to be 'extra sure' I also have it on the ELK interface. "
It DOESNT work that way!!! You can not place egress rules on interface tab, the only place you can do egress filtering is via floating tab..
-
You can not place egress rules on interface tab
This was about the first two rules, which are ingress filters.
the only place you can do egress filtering is via floating tab
Ok, perhaps I use the terms 'ingress' and 'egress' in the wrong context. With egress I mean blocking a device on the elk net towards any other interface including the internet. Derelict seems to imply that my guess was correct and that I can do that filtering on the ELK interface. You seem to imply that it is only possible using floating rules.
Could someone please clarify?
If you have Block source ELK Net dest any on the ELK interface and ELK net can still establish new connections, the traffic is being passed by something else.
I checked my state table, and the connections to the internet I initiate in the 192.168.2.2 device are listed as a state on the WAN interface.. any explanation for this?
-
OK. First, execute this in Diagnostics > Command Prompt: pfctl -nf /tmp/rules.debug
That should produce no output. If it does, paste it here.
Second, assuming that runs clean, execute this in Diagnostics > Command Prompt: cat /tmp/rules.debug
Copy and paste that in a private message to me.
We will get to the bottom of what your problem is once and for all.
-
All traffic is filtered on interfaces going the same direction: It is all INGRESSING the firewall on that interface.
You can make a special case using floating rules in the OUTBOUND DIRECTION on an interface. That is EGRESS filtering.
I get what you are saying but calling a rule on an inside interface EGRESS filtering is simply not the proper way to refer to it.
-
"This was about the first two rules, which are ingress filters."
How is dest 192.168.2.2 ingress?? When that is your server?? That is on elk net??
"With egress I mean blocking a device on the elk net towards any other interface including the internet"
From that interface - yes that is egress.. But that traffic is ingress to the elk net interface on pfsense. And how would the destination ever be 192.168.2.2??? And you rule said ALLOW anyway..
-
Alright guys, it is starting to make a lot more sense now.
So rules are activated on packets coming IN to an interface. Once the packet is inside the interface, it is free to go OUT where it likes to, UNLESS there is a quick floating rule which is configured in the out-direction. That does not mean we can't have a rule to filter traffic going to the internet. That specific packet will need to go IN an interface first, and then the rules will be checked.
Two questions remain:
-
Then why doesnt the 'Block source ELK Net dest any on the ELK interface' stop internet traffic?
-
In case all unspecified traffic is blocked by default, I can actually drop the 'Block source ELK Net dest any on the ELK interface' completely, right? But the question still remains as to why my device has internet connectivity
Derelict, thanks for offering to help. I've sent you a PM.
-
-
OK. And what traffic, specifically, do you think should be blocked? Please use complete information. Source interface and IP address, destination IP address, protocol, and port.
-
The specific packets I want to have blocked appear in my WAN state table (with my WAN IP), whereas I would expect them to be in the ELK state table (with their local IP).
I'm testing with 'example.com', IP address 93.184.216.34 in my case.
So: source 192.168.2.2 dest 93.184.216.34:80
-
Pretty sure transparent squid is passing that traffic. Do you need transparent squid on that interface?
(You could have mentioned squid…)
-
Yes, seems to do the trick. Sorry for not mentioning it (I've added my enabled services to my signature now, so I don't forget next time).
Does that mean that I cannot trust rules on interfaces which have Squid enabled?
-
Transparent squid is an implicit pass to port 80 (and 443 if enabled). If you want to bypass that for certain sources, you have to do that in squid. If bypassed they should fall through to the interface rules for those ports.
-
"Does that mean that I cannot trust rules on interfaces which have Squid enabled?"
Well yeah if your going to run it in transparent mode ;) Run it in implicit mode and setup the clients you want to use to use it.. And place a rule on your interface to allow access to the squid port for only the clients you want to be able to use it.. This way you know what clients are using squid and which can not, etc.
You made no mention of squid and you have no rules on your interface that even suggest you would allow such traffic.. If you do not tell us what your doing, its hard to look into our crystal ball and find out.
-
Well thank you both for the explanation. I understand the rule engine much better now. As for squid, it is a bit of a surprise to me that the redirect of 80-443 traffic to squid happens before the fw rules are applied. Is there a specific reason for this?
-
https://doc.pfsense.org/index.php/Firewall_Rule_Processing_Order
More accurately, the following order (still simplified) is found in the ruleset (Check /tmp/rules.debug):Outbound NAT rules
Inbound NAT rules such as Port Forwards (including rdr pass and UPnP)
NAT rules for the Load Balancing daemon (relayd)
Rules dynamically received from RADIUS for OpenVPN and IPsec clients
Internal automatic rules (pass and block for various items like lockout, snort, DHCP, etc.)
User-defined rules:
Rules defined on the floating tab
Rules defined on interface group tabs (Including OpenVPN)
Rules defined on interface tabs (WAN, LAN, OPTx, etc)
Automatic VPN rulesWhen you have squid in transparent mode there is a RDR to redirect the 80/443 traffic to the squid proxy port. This happens before the other rules are applied. To be honest I don't see why anyone would want to run a proxy in transparent mode ;) You can always hand out the proxy info to your clients via wpad if you want, etc. Transparent not something I would suggest.. Atleast these way the client should be aware that they are using a proxy.. Or at least simple enough for them to determine it.. Transparent is doing a redirect that they might not be aware of. Not a fan of such behavior.. I would not like it if I was a user of that network for sure, so why should I impose such shenanigans on my network, etc.. ;)
-
Interesting discussion, I'm of a different opinion. Users do never know what happens with their traffic, whether it's part of their network setup or the next (e.g. ISP ). Inspection happens all te time, and users should protect themselves in other ways (using https is one way, I'm not a fan of decrypting ssl in squid).
In any case, the fact that my fw rules are bypassed is quite the party crasher, in a bad sense.
-
Yeah. People enable packages all the time without realizing what they do or even what they are for.
Your transparent squid was behaving exactly as expected.
-
Glad to learn something new every day!
You seem to imply that it is documented somehow that enabling squid breaks your firewall rules. I don't think it is, which is why we need experienced people like you to help. Looking at the rule order, it makes sense that squid breaks the rules, though I cannot imagine that it is behaviour that the squid developers intended.
Kind regards,
Michael