firewall allowing WAN to connect to Google DNS servers

Started by Inxsible, March 03, 2021, 07:18:05 AM

Previous topic - Next topic
Quote from: marjohn56 on March 04, 2021, 04:30:58 PM
Of course, if you want total privacy, use a VPN. Of course this will not stop pesky devices like Chromecast from using 8.8.8.8, but it's on my IOT VLAN anyway, so who cares.
I do use a VPN but I do network based routing (WORK AND IOT exit the ISP gateway, the rest exit the VPN gateway).

And yes, my Chromecast & Roku are on the IOT network and I don't care about that.


Your Firefox does something strange? Why not have a look there in the first place? What kind of (mis)config of DNS do you use here? Nobody knows your setup, so nobody can really help you.
kind regards
chemlud
____
"The price of reliability is the pursuit of the utmost simplicity."
C.A.R. Hoare

felix eichhorns premium katzenfutter mit der extraportion energie

A router is not a switch - A router is not a switch - A router is not a switch - A rou....

Quote from: chemlud on March 04, 2021, 05:53:15 PM
Your Firefox does something strange? Why not have a look there in the first place? What kind of (mis)config of DNS do you use here? Nobody knows your setup, so nobody can really help you.
I just laid out all the rules and my network layout. Is there anything specific that you need to know. Please let me know and I can go find that info.

Aren't floating rules applied before the manually set up rules on the individual interfaces?

I don't see anything in my firewall logs that uses the rules that I set up. Everything is passed by the auto-generated Floating rules.

can someone please help me out in blocking this traffic?

Your FW rules look all messed up to me. I think you are confused by how the rules work. Have you read the OPNsense docs on firewall rules? You need to have a look at that, particularly to understand rule direction, quick vs non-quick, and logging

Your LAN/VLAN rules need to be applied from the perspective of traffic coming from the relevant subnet into the relevant interface on OPNsense. So rules are applied INto the interface, and have a source of the subnet. If you want to see those rules in the logs, turn on logging for them

You are seeing the floating rule only in the logs because that is the only relevant one with logging turned on. And you are seeing the operation of that rule because two things are happening - packets are coming into OPNsense on the LAN/VLAN interfaces and being processed by the rules that apply there, then they are being NATted and are being passed out of OPNsense on the WAN interface by the floating rule that applies there

Quote from: Greelan on March 04, 2021, 08:06:45 PM
Your FW rules look all messed up to me.
Can you please explain how they are messed up?

Quote from: Greelan on March 04, 2021, 08:06:45 PMI think you are confused by how the rules work. Have you read the OPNsense docs on firewall rules?
Possibly I am. I have read the Opnsense docs on Rules.
Processing Order indicates that the Floating rules are used before the Interface rules. The note then indicates that Automatic rules have higher priority.

Quote from: Greelan on March 04, 2021, 08:06:45 PMYou need to have a look at that, particularly to understand rule direction, quick vs non-quick, and logging
Yeah, the direction was not something that pfSense had, so I will have a look at those again to make sure I have the rules set up correctly
Quote from: Greelan on March 04, 2021, 08:06:45 PM
Your LAN/VLAN rules need to be applied from the perspective of traffic coming from the relevant subnet into the relevant interface on OPNsense. So rules are applied INto the interface, and have a source of the subnet. If you want to see those rules in the logs, turn on logging for them
All the rules that I manually created on the individual networks are defined as IN direction.

Quote from: Greelan on March 04, 2021, 08:06:45 PM
You are seeing the floating rule only in the logs because that is the only relevant one with logging turned on. And you are seeing the operation of that rule because two things are happening - packets are coming into OPNsense on the LAN/VLAN interfaces and being processed by the rules that apply there, then they are being NATted and are being passed out of OPNsense on the WAN interface by the floating rule that applies there
Yes, I'll enable logging for all the other rules for debugging purpose and see which rules are being applied.

But I am still concerned about the fact that the auto-generated rules that were created trumps all the manual rules that I have. Is that not the case?

Quote from: chemlud on March 04, 2021, 05:53:15 PM
Your Firefox does something strange? Why not have a look there in the first place? What kind of (mis)config of DNS do you use here? Nobody knows your setup, so nobody can really help you.
This turned out to be a Firefox profile issue. I created a new firefox profile and that correctly gives me the IP of my VPN exit node as my only DNS server in both Chromium & Firefox.

March 04, 2021, 08:48:44 PM #23 Last Edit: March 04, 2021, 08:50:38 PM by Greelan
Quote from: Inxsible on March 04, 2021, 08:34:06 PM
But I am still concerned about the fact that the auto-generated rules that were created trumps all the manual rules that I have. Is that not the case?

No. Again, different interfaces. And you are not taking into account quick vs non-quick rules - again, see the docs

BTW, pfSense does in fact employ pretty much the same concepts as OPNsense on rule direction etc under the hood, it is just that it does not make as much of that explicit in the GUI. For example, by default pfSense firewall rules on an interface are applied into the interface, because that's the 99% use case. OPNsense just gives more flexibility if needed

Quote from: Greelan on March 04, 2021, 08:48:44 PM
Quote from: Inxsible on March 04, 2021, 08:34:06 PM
But I am still concerned about the fact that the auto-generated rules that were created trumps all the manual rules that I have. Is that not the case?

No. Again, different interfaces. And you are not taking into account quick vs non-quick rules - again, see the docs
I have all my manual rules set up as Quick and direction=IN (which is the default). I also noticed that the auto-generated rules that I was talking about are all Non-Quick and with direction=OUT

Maybe it is just a matter of me reading the log files incorrectly.

When I see an outgoing connection from my WAN IP or my VPN IP to other DNS servers with port 53 -- is that just Unbound contacting the root servers?

When I look at the firewall log with the direction = IN as the search criteria, I only see the Loopback interface and my LAN services connecting to my firewall address on port 53


Thanks for sticking by me... I really appreciate it.

Bit hard to tell without seeing all the relevant bits of the setup, packet traces etc (and I don't want to see them lol). Bear in mind that what unbound is doing depends on whether it is a recursive or forwarding resolver. If recursive, it won't just be contacting the root servers, but a whole array of nameservers out there as it recursively resolves names. So will you see requests to Google, Cloudflare etc etc

March 05, 2021, 12:34:01 AM #27 Last Edit: March 05, 2021, 12:48:45 AM by Inxsible
Quote from: Greelan on March 05, 2021, 12:00:59 AM
Bit hard to tell without seeing all the relevant bits of the setup, packet traces etc (and I don't want to see them lol). Bear in mind that what unbound is doing depends on whether it is a recursive or forwarding resolver. If recursive, it won't just be contacting the root servers, but a whole array of nameservers out there as it recursively resolves names. So will you see requests to Google, Cloudflare etc etc
That probably is what it is then. I have unbound set up as a resolver and not a forwarder.

Last question: I know that Automatic rules have higher priority, but are auto-generated Non-Quick Floating rules matched before the Quick rules on any interface?

No.

Floating rules are evaluated first, but if it is a non-quick rule then rule evaluation continues to determine if another quick or non-quick rule matches. If none, then the initial non-quick rule is applied. But if a matching quick rule is reached (including on an interface) then evaluation stops and the quick rule is applied. If other non-quick rules are matched, then the last of those is applied.