Outbound traffic not blocked
I'm trying to do basic egress filtering. I have configured the following rules on the interface:
These are my floating rules:
I am still able to access external hosts via a host on the interface. I must also add that I have enabled NAT. The device i'm testing with is 192.168.2.2, which happens to also be configured for port forwarding:
What I want to achieve:
192.168.2.2 should be accessible from the internet on port 80 and 443
192.168.2.2 should not be able to contact external servers, except for the ACME and AUTH0 aliases.
what interface is that first pic?
Your rules don't make any sense.
Rules on floating are applied to what interfaces?
Rules are evaluated as the traffic enters an interface from that network. First rule to trigger wins, no other rules are evaluated. Rules on floating are evaluated before interface rules, but are not set to be quick unless you set it, etc.
If you want 192.168.2.2 to be available from the internet to 80/443 then that would be a port forward.
If you don't want 192.168.2.2 to access the internet other than amce and auth0 aliases then those rules would be placed on the interface that 192.168.2.2 is connected too.. And there would be little reason do put such rules on floating.
Thanks for your reply. First pic is for the "Elk" interface, to which I have physically connected one device: 192.168.2.2. This interface is configured as a 192.168.2.0/24 network.
Why don't my rules make any sense? I posted the floating tab just as extra information. I have to check to which interfaces they apply (there are many vlans). There shouldn't be specific floating rules for the "elk" interface.
As to your last 2 paragraphs. That's exactly what I tried (I think). Is there something in my rules which contradicts that?
"Why don't my rules make any sense?"
Because if they are on the elk interface there would never ever be inbound traffic to pfsense elk interface with a dest of 192.168.2.2 - NEVER!! So rule is pointless..
Nor would there ever be inbound traffic from the elk address of pfsense elk net 192.168.2/24
rules are evaluated INBOUND into the interface from the network - towards pfsense.. So those first 3 rules don't make any sense. Your 2nd two rules don't show any hits – the 0/0 So maybe your floating rules are doing something.. Maybe your pfb threat rules... They show some hits.. But without know what interface they are set to, if in or out and if quick set its hard to say what they could be doing.
As to you being able to access stuff after you create rules.. Did you flush any existing states?
I'm still not entirely clear on this. You say that my first three rules don't make sense because only inbound traffic is checked. But that would mean my last two rules also don't make sense because they are meant for outbound traffic.
If rules are only applied inbound, then how am I able to block outgoing traffic?
Sorry if I'm missing the point but I'm a bit confused now.
Outbound from pfsense.. The traffic is evaluated as it enters an interface… Pfsense does not then check it again for outbound your wan, unless you have a floating rule set to check outbound, and floating are evaluated before interface rules anyway.
So as the traffic enters your elk interface it walks down the rules..
So lets say your 192.168.2.2 is talking ipv4 with dest port 443 tcp to lets call it 184.108.40.206 lets walk down the rules.
First rule.. dest 2.2, does not trigger
2nd rule dest 2.2 again does not trigger. Neither of these would ever trigger because what traffic would ever be sent to the elk interface for a dest of 192.168.2.2 - it would never happen..
3rd rule how would traffic from 192.168.2.1 ever be inbound into pfsense elk interface which is 192.168.2.1, etc.. so not triggered.
4th rule.. Ok its tcp, its coming from elk net 192.168.2/24 its 443 traffic.. So is the dest inside your acme alias - if not, then not trigger if so then triggered and allowed. That is it pfsense would allow that traffic to wherever acme is.. be it out another local interface or out the wan..
5th rule would never be looked at unless 220.127.116.11 was not in acme, if not then is it in auth0.. If so would be allowed. If not - then no other rules would hit the default deny! and not be allowed..
Think of it as a doorman standing between the elk net and pfsense.. He checks the list (firewall rules) if allowed your allowed past him, if not on the list or a deny rule then your not even allowed in. Once your into pfsense then your in.. You can go where ever you want, be it to pfsense, to internet, to another local network, etc.
If you want to allow or block something on elknet from going some where you do it on the elk interface.. Since this is where traffic would first enter pfsense.. But something on elknet is not going to send traffic to pfsense if the traffic is to something else on elknet.. Only ever going to send traffic to pfsense (its gateway) when the dest is not elk net..
I'm trying hard to make sense of this.
first two rules are there to allow access from the internet to 192.168.2.2 via NAT. Packets from Eg 18.104.22.168 would have to pass the ELK interface doorman, right?
third rule is there to allow logs being sent from the firewall (2.1) to the device (2.2). Probably this is allowed by default and can this be removed
last two rules are there to ONLY allow access from 2.2 to acme and auth0. There is no other rule allowing outbound traffic from ELK to the internet.
I cleared the state table, and 2.2 still has access to the internet.
I'm very glad that you're helping me, but I must admit it is difficult for me to follow your reasoning.
Could you give an example of a fictive interface and the rules I would need to do the following:
allow access to one device on the fictive interface from the internet via NAT
block all outbound access except for an alias.
"first two rules are there to allow access from the internet to 192.168.2.2 via NAT."
No they are not.. It doesn't work that way!!! If you want the internet to get to 192.168.2.2 you would do a port forward and the rules that allow that traffic would be on your wan interface - not elk.
"third rule is there to allow logs being sent from the firewall (2.1) to the device (2.2)"
Again NO… it doesn't work that way! If you want to stop pfsense from talking to something you would have to do it on floating tab as egress from the interface.. That rule on elk would never be evaluate for pfsense sending traffic..
"allow access to one device on the fictive interface from the internet via NAT"
This is a simple port forward.. Port forward 80 and 443 to 192.168.2.2, this will auto create your wan firewall rule for you.
"block all outbound access except for an alias."
Your last 2 rules already do that.. But you have no rule to allow 192.168.2.2 to do any dns..
Alright, I think I'm starting to get it.
So you mean that all interfaces are actually grouped together as being 'PFSENSE'. And then, only inbound traffic to PFSENSE is evaluated, no matter to which interface the traffic is going. If the traffic happens to hit the ELK interface first, those rules will be evaluated, if it happens to hit WAN first, then those rules would be evaluated, etc.
But if that reasoning is correct, then it would be strange because there would be no way to block traffic between the WAN interface and the ELK interface (e.g. to block VLAN routing), because both interfaces are part of the big 'PFSENSE', and once I have access to PFSENSE, there are no doormen anymore?
As for DNS, I have a floating rule to allow for DNS.
In https://forum.pfsense.org/index.php?topic=56558.0, the following is mentioned:
@pv2b - you've discovered one of the many reasons it's best to block the traffic as close to the source as possible.
Sure an outbound floating rule shortcut sounds convenient, but ultimately it's best to block on the individual tabs (or both, just to be extra sure).
This conflicts quite with what you said. I understand from the above that I should block outbound traffic on the interface itself..
"This conflicts quite with what you said. I understand from the above that I should block outbound traffic on the interface itself.."
Oh my gawd dude no it doesn't!!!!
What you quote there is saying block outbound traffic on the interface as it enters pfsense.. And if you want you could also block it on the egress rule via a floating tab.. to be "extra sure"
Interface tabs do not block "outbound" of the interface.. Only inbound towards pfsense from the network they are connected too. If you want to block on the OUTBOUND or egress direction of an interface then you would have to do it on the floating tab.. pick direction outbound.
But why would you let traffic even into pfsense just to block it from leaving??? So you block it at the interface tab before it even enters pfsense..
If you don't want devices to leave the elk network, then you block that traffic on the elk interface before it even gets inside of pfsense.
If you don't want devices to leave the elk network, then you block that traffic on the elk interface before it even gets inside of pfsense.
I believe that is what I want to achieve. And how would I do that? I tried a block any source:elknet destination:any, but traffic was still going through…
By the way, in https://forum.pfsense.org/index.php?topic=114696.0 they explain it like:
A subtle distinction about rules in pfSense that may differ from other products: they are applied in the inbound direction on an interface. Inbound means you are sitting in the middle of the box, between the LAN and WAN. Traffic from your clients is inbound on LAN; traffic from the rest of the world is inbound on WAN. That's why you add the rule to the LAN interface.
It seems to me that outbound filtering is not as clearly documented as ingress filtering.
Moreover, following that quote, the first two rules still keep making sense to me: I want to allow traffic from the internet to 192.168.2.2, so I have that rule with source:any towards destination:192.168.2.2. I also have that rule on the WAN side, but to be 'extra sure' I also have it on the ELK interface.
Unless you are using floating rules it is all ingress filtering.
Rules control traffic going into an interface. 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. About the only places those rules could be are either higher rules on that interface, on an interface group containing ELK, or a floating rule operating on ELK in the in or any direction.
" 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 22.214.171.124 in my case.
So: source 192.168.2.2 dest 126.96.36.199: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?
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.)
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 rules
When 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.