Firewall rules / problem with blocked traffic / no clue what goes wrong
-
Hi guys,
I have multiple VLANS in my home.
As I love playing around with that kind of stuff I tried to apply a ruleset to my IOT VLANIn my IOT VLAN there is also my PS5, which has a simple rule:
The PS5 is allowed to do any outbound traffic on any port, exempt accessing the firewall itself. Note The tracking id of the firewall rule
LAN_IOT has a specific ruleset to allow only desired outbound traffic. At the bottom i have a rule that blocks all traffic that has not allowed on purpose. Note the Tracking id as well
According to my understanding the firewall processes the ruleset from top to bottom. Which means, first rule fits, first applies.
I face sudden disconnects from online gaming and voice chats. I checked the firewall logs where I can see that the "general bock" rule applies.
Why does this happen, what is wrong in the configuration?
According to my understanding the first rule that allows anything for the IP of my PS5 should be perfectly fine. -
Your first rule allows talking to the firewall on any of its IPs, your 2nd rule blocks everything else..
No that is not going to work for internet access..
edit: Oh you have that set as inverted rule? Why?
Your blocks are Ack, so out of state.. See how your syn there is allowed to 2.18.255.130 on 443
edit2: Your rule being an inverted rule, allows anything not to the firewall, so those rules at the bottom allowing like smtp, etc. are all pointless..
edit3: The use of inverted rules can be problematic, at least they use to be - if you had vips on the interface, etc. I wouldn't do the rules like that at all.. Also with your ! rule to firewall, you could talk to any of your other networks/vlans, so those rules blocking access are also pointless since you allowed them in the first rule. Rules are evaluated top down, first rule to trigger wins, no other rules are evaluated.
Here is a basic set of rules that allow anything to internet, which your trying to do with the first rule, but blocks all other stuff.
Allows ntp, dns and ping to the firewall.. This is normal stuff you would want to be able to do to the firewall - ping to validate you can talk to it :) and then dns and ntp.
There is no need for a block rule at the end, unless you don't want to log or something - since by default all traffic is blocked unless allowed in a rule.
-
Please see changed ruleset according to your advices:
- All IOT devices can access PLEX media Server
- All IOT devices can access local DNS Server, NTP Service and perform pings in VLAN
- Traffic to "This firewall" and "privat networks" is blocked for all devices (exempt plex which has its allow rule before)
- PS5 and the AV-Reciever have some IP based special rules
- Allow basic Internet access
Note: LAN_IOT consists of multiple devices. TV´s, AV-Receiver, LAN Radio, etc.
Rest is blocked as not explicitly allowed
Hope I got it now :)
Thank you for your advices
-
@frosch1482 that looks better for sure.
I don't get the multicast 5353 to 1900 to be honest.. And not sure how those would do anything.. Lets say you passed 5353 to via avahi, and you got back some dns answer from something else on your network so it could then connect to it - but you would then block that connection via your above rule that blocks all access to rfc1918.
Do you have UPnP enabled.. What is going to be created via that? Do you have UPnP locked down? Also 1900 is used for discovery as well, but even if you pass that with avahi and discovered something SSDP, you wouldn't be able to connect, again when the connection is attempted it would fail because of your block rule to rfc1918..
I guess your 29.3 could connect via something it discovers with 5353/1900 via multicast being passed with avahi to something on your network on port 51200?
edit: Also the smtp rule.. Do you have something talking to the internet on 25? Email clients would almost never do this, 25 is mostly done for email server to email server communications. I guess there are some clients that could send email to the isp smtp server via 25.. But this is rarely done any more.. I don't see any hits on that rule - you could prob remove it.
-
you could be right with the 5353, 1900. I have to analyse it deeper these days. If I remember it right, all Spotify stuff is managed via remote server (Spotify is the reason of Avahi). Nothing is done in the local network, exempt "discovery" of the device. But it is a long time ago, I analyzed that stuff in detail.
Isn´t all that multicast traffic on 224 or 225 networks? in this case it shouldn´t be in conflict with the block RFC1918 rule
Edit:
The new rules did not solve my initial issue
Any other idea?
-
@frosch1482 said in Firewall rules / problem with blocked traffic / no clue what goes wrong:
Isn´t all that multicast traffic on 224 or 225 networks? in this case it shouldn´t be in conflict with the block RFC1918 rule
Yeah while the discovery would be multicast.. Which you seem to be passing with avahi? But if it finds something on 192.168.1.100 for example via that multicast discovery.. And then wanted to connect to 192.168.1.100 - that would be blocked.
So what is the point of the discovery in the first place?
