Firewall 101
-
Hi,
I've been reading the doco for firewall rules here however I'm kind of struggling.
It says that rules are "inbound only" and that outbound rules are not needed. But what is inbound? I mean if a device on LAN sends out to the internet, technically it sends packets that are inbound to the lan interface right? But then the reverse is also true, packets coming from the WAN are also inbound to the LAN interface, so I am really confused.
Can anyone help with like a picture or something? Thanks.
-
@propercactus said in Firewall 101:
But then the reverse is also true, packets coming from the WAN are also inbound to the LAN interface,
Not really, you have to take the perspective of the firewall. WAN-traffic is only inbound to the firewall coming from WAN. If this traffic is going further to LAN, it then has become outbound in the perspective of the firewall.
LAN-traffic is inbound to the firewall when it enters from the LAN-Interface.
So in short, filtering is done where the traffic enters the firewall. -
@bob-dig said in Firewall 101:
So in short, filtering is done where the traffic enters the firewall.
So in the situation where I have a device sending from LAN out to the internet, the packet enters LAN interface, that is inbound to the LAN interface? It then gets passed to the WAN interface to be sent out to the internet.
But you are saying that it will only be filtered according to rules for the LAN interface right? Once it's passed to WAN to go out it is not filtered again?
And then similarly, when a response comes back from the WAN, it enters into the WAN interface, gets filtered by WAN rules and then gets passed to LAN and no LAN filters are applied?
-
I'm trying to work out how to do Egress filtering, I follow the article by Netgate here yet it stops short of mentioning any way to implement the actual rule to block all edgress traffic, and also doesn't mention how we make rules to allow our chosen services like HTTPS out.
I've tried making a floating rule that blocks all out and then a floating rule to allow HTTPS out but it just broke everything.
-
@propercactus said in Firewall 101:
@bob-dig said in Firewall 101:
So in short, filtering is done where the traffic enters the firewall.
So in the situation where I have a device sending from LAN out to the internet, the packet enters LAN interface, that is inbound to the LAN interface? It then gets passed to the WAN interface to be sent out to the internet.
But you are saying that it will only be filtered according to rules for the LAN interface right? Once it's passed to WAN to go out it is not filtered again?
And then similarly, when a response comes back from the WAN, it enters into the WAN interface, gets filtered by WAN rules and then gets passed to LAN and no LAN filters are applied?
Yes you got it.
Floating rules are the only exception. Don't use them if you don't have to.
-
@propercactus said in Firewall 101:
I'm trying to work out how to do Egress filtering,
Egress filtering according to your link is just done on LAN, no floating rules needed.
-
@bob-dig said in Firewall 101:
Yes you got it.
I don't think it's right because I set to block everything on LAN and allow HTTPS, then on the WAN I also block everything and nothing passes through until I allow HTTPS on the WAN as well as LAN.
-
-
@propercactus By default WAN has no rules, so everything incoming is not allowed by default = blocked. On LAN you have a allow anything rule by default. There you have to alter things.
-
@propercactus said in Firewall 101:
I have to allow HTTPS on both
No. On WAN you only filter incomming traffic from WAN.
If your WAN is behind another router, don't forget to uncheck "Block private networks and loopback addresses" in the interface settings. -
@bob-dig said in Firewall 101:
No. On WAN you only filter incomming traffic from WAN.
If your WAN is behind another router, don't forget to uncheck "Block private networks and loopback addresses" in the interface settings.Ok so I've removed the WAN block/allow rule and now my rules look like this:
WAN:
LAN:
And it does not let me connect to sites over https
Or do I need a matching inbound rule for HTTPS on the WAN to compliment the outgoing rule for HTTPS on the LAN? I thought that stateful firewall means that if I can send out on HTTPS it allows back in by default?
-
@propercactus said in Firewall 101:
Or do I need a matching inbound rule for HTTPS on the WAN to compliment the outgoing rule for HTTPS on the LAN? I thought that stateful firewall means that if I can send out on HTTPS it allows back in by default?
True, you normally don't need any rules on WAN.
Is DNS working?
-
@bob-dig yea DNS is resolving, it's being resolved by unbound on pfsense
-
@propercactus But does it work for hosts on green...
"DNS internal hosts" looks weird to me.
-
@propercactus It works while I'm on green yea, because it's asking the pfsense unbound for lookups.
If say I try and query cloudflare directly from green, no it doesn't but that's expected because I have that reject all rule on green and I haven't allowed DNS right?
-
@propercactus your dns rule is probably wrong. Destination would be "green address" under normal circumstances.
-
@bob-dig said in Firewall 101:
@propercactus your dns rule is probably wrong.
Nah it's definitely resolving DNS. it gives a DNS_PROBE_ERROR in chromium when DNS failes.
I'm getting ERR_CONNECTION_REFUSED so it it port 443 that is being rejected.
-
Why would you allow management from RED? Wan??
Red Blue Green - you a IPcop user?
What is in your dns_internal_hosts alias? You understand that the gateway (pfsense) to get off green is not talked to talk to something on the green network. Do you have some IP that is say blue network in this alias? Also dns is not "always" only udp, tcp can be used for dns over 53.. Your dns rule should allow both udp and tcp to 53
Do you have any rules in floating?
Also your browser saying rejected.. Who said it was pfsense that rejected it - maybe it was the server you were trying to talk to? Browser errors are horrible for troubleshooting a firewall with - did pfsense log that it blocked where you were trying to go. You don't have a reject setup for ipv4 other ports since you have 443 allowed above it, all ipv6.. Did your browser try and use IPv6 maybe? Look to the firewall log to what was blocked or rejected.
-
@johnpoz said in Firewall 101:
Red Blue Green - you a IPcop user?
Yea IPFire haha, I've just made the switch to pfsense.
@johnpoz said in Firewall 101:
What is in your dns_internal_hosts alias?
Yea I have another DNS server across the WireGuard S2S link, it's in the 10.1.0.0/18 range and so I've just put all the local DNS servers on this side of the WAN into one alias and allowing to them.
@johnpoz said in Firewall 101:
Also dns is not "always" only udp, tcp can be used for dns over 53
That's right and I'm using DoT (TCP/853) out bound from pfsense. My DNS is working all good. I just can't get HTTPS to work, the rule flow as you describe it is not working, i reject all on LAN (GREEN) and I allow HTTPS on LAN, however unless I put a matching rule on RED (WAN) it will not let me connect to any sites on 443.
-
@propercactus said in Firewall 101:
That's right and I'm using DoT (TCP/853) out bound from pfsense
which has ZERO to do with any rules.. Unless you setup outbound rules on floating?
-
@johnpoz said in Firewall 101:
Unless you setup outbound rules on floating?
Nah I removed all my rules from floating and anywhere else, what you see is all my rules.
And I rebooted the device.
-
dot over 853, sure ok use tcp.. But normal dns over 53 can also use tcp..
Its been years and years since played with ipcop or ipfire - but I don't recall them using any outbound rules either. Was always inbound to the interface for rules.
-
@johnpoz said in Firewall 101:
But normal dns over 53 can also use tcp..
Yes that's right but in my case all DNS locally is 53/UDP and it goes out TCP/853 for external look ups.
@johnpoz said in Firewall 101:
Its been years and years since played with ipcop or ipfire - but I don't recall them using any outbound rules either. Was always inbound to the interface for rules.
Yea so you can configure the default behaviour of the firewall in IPFire. So yes by default it allows all out, but in Firewall settings you can set it to default block all out, and then we just choose what we want to allow out.
-
@propercactus said in Firewall 101:
all DNS locally is 53/UDP
That is not always true.. DNS client can switch to tcp when the answer is larger than what udp would allow for. Which use to be 512, with edns that has gotten larger and normally defaults to 4096. But it is not good practice to prevent a client from using tcp over 53, in the event answer to what its looking for exceeds the max size that can be done over udp. And it would have to switch to tcp.
-
@johnpoz said in Firewall 101:
DNS client can switch to tcp when the answer is larger than what udp would allow for
Ok I changed that rule to allow TCP/UDP.
Error still remains tho, I cannot get to any website.
-
Did you look at the firewall log to see if blocking anything - if not logged in pfsense, again your browser error is not always good source of where something prevented you from doing something.
And just to be complete. Here is test showing client switching to TCP over udp doing a test where I turned off edns with +noedns in the query..
dig @192.168.9.253 test.knot-resolver.cz. TXT +noedns
You can see in the sniff client switched to tcp
If pfsense is not logging that it blocked where you were trying to go in the browser - then sniff on pfsense wan (red) and did the traffic get sent?
-
@johnpoz said in Firewall 101:
dig @192.168.9.253 test.knot-resolver.cz. TXT +noedns
I think the floating rules table was gammied up? I added a rule in floating to allow all HTTPS, then I deleted that rule and now it is working.
