Need help with my VLAN firewall rules to make sure they do what I think they do
-
I'm setting up VLANs and FWs for the first time. I want to make sure my understanding is right and there aren't any obvious mistakes that I'm missing.
I have 4 VLANs:
VL10_dmz
- a single server running numerous services in Docker
- some Docker containers will be internet accessible (HTTPs and Plex to start with)
- needs to be able to make HTTP, HTTPS, and FTP calls out for
apt
- should only allow SSH in from
VL20_trust
VL20_trust
- my home computers and Roku
- should be able to SSH to
VL10_dmz
- should have un-restricted internet access
- devices should not be able to talk to each other unless I specify the allowed IPs/ports (nothing to start with)
- I don't think I can actually do this since they are all in the same VLAN and the switch will handle it, not pfSense
- Since my Roku is on the same VLAN as my iPhone, I assume I don't need any special rules for letting me use the iOS app to control the Roku
VL30_iot
- IoT
- devices should be able to talk to each other but no other VLANs
- should have un-restricted internet access
- shouldn't be able to access pfSense
VL40_guest
- Guest
- devices should not be able to talk to each other
- I don't think I can actually do this since they are all in the same VLAN and the switch will handle it, not pfSense
- should have un-restricted internet access
- shouldn't be able to access pfSense
These are the rules I've come up with:
interface: WAN
action address family protocol src des description block
IPv6
any
any
any
block everything IPv6 from WAN
block
IPv4
any
any
any
block everything IPv4 from WAN
interface: LAN
action address family protocol src des description reject
IPv6
any
any
any
:any
reject everything IPv6 from LAN
pass
IPv4
udp
LAN net
127.0.1.1
:NTP (123)
port forwarding of NTP from LAN to pfSense
pass
IPv4
tcp/udp
LAN net
127.0.1.1
:DNS (53)
port forwarding of DNS from LAN to pfSense
pass
IPv4
tcp/udp
LAN net
LAN address
:HTTP (80)
pfSense anti-lockout rule for LAN: HTTP
pass
IPv4
tcp/udp
LAN net
LAN address
:HTTPS (443)
pfSense anti-lockout rule for LAN: HTTPS
pass
IPv4
tcp/udp
LAN net
LAN address
:SSH (22)
pfSense anti-lockout rule for LAN: SSH
pass
IPv4
icmp
/Echo request
LAN net
any
:any
allow pinging from LAN
pass
IPv4
tcp/udp
LAN net
any
:any
allow LAN to access anything
reject
IPv4
any
any
any
:any
reject everything else IPv4 from LAN
interface: V10_dmz
action address family protocol src des description reject
IPv6
any
any
any
:any
reject everything IPv6 from V10_dmz
pass
IPv4
udp
V10_dmz net
127.0.1.1
:NTP (123)
port forwarding of NTP from V10_dmz to pfSense
pass
IPv4
tcp/udp
V10_dmz net
127.0.1.1
:DNS (53)
port forwarding of DNS from V10_dmz to pfSense
pass
IPv4
tcp
V10_dmz net
!
Network
=192.168.0.0
/16
:HTTP
allow V10_dmz outside of the local network: HTTP
pass
IPv4
tcp
V10_dmz net
!
Network
=192.168.0.0
/16
:HTTS
allow V10_dmz outside of the local network: HTTPS
pass
IPv4
tcp
V10_dmz net
!
Network
=192.168.0.0
/16
:FTP
allow V10_dmz outside of the local network: FTP
pass
IPv4
tcp
V10_dmz net
!
Network
=192.168.0.0
/16
:43
allow V10_dmz outside of the local network: WHOIS
reject
IPv4
any
any
any
:any
reject everything else IPv4 from V10_dmz
interface: VL20_trust
action address family protocol src des description reject
IPv6
any
any
any
:any
reject everything IPv6 from VL20_trust
pass
IPv4
udp
VL20_trust net
127.0.1.1
:NTP (123)
port forwarding of NTP from VL20_trust to pfSense
pass
IPv4
tcp/udp
VL20_trust net
127.0.1.1
:DNS (53)
port forwarding of DNS from VL20_trust to pfSense
pass
IPv4
tcp/udp
VL20_trust net
VL20_trust address
:HTTP (80)
pfSense anti-lockout rule for VL20_trust: HTTP
pass
IPv4
tcp/udp
VL20_trust net
VL20_trust address
:HTTPS (443)
pfSense anti-lockout rule for VL20_trust: HTTPS
pass
IPv4
tcp/udp
VL20_trust net
VL20_trust address
:SSH (22)
pfSense anti-lockout rule for VL20_trust: SSH
pass
IPv4
icmp
/Echo request
VL20_trust net
any
:any
allow pinging from VL20_trust to anything
pass
IPv4
tcp
VL20_trust net
VL10_dmz address
:SSH (22)
allow VL20_trust to SSH to VL10_dmz
pass
IPv4
tcp/udp
VL20_trust net
!
Network
=192.168.0.0
/16
:any
allow internet for VL20_trust
reject
IPv4
any
any
any
:any
reject everything else IPv4 from VL20_trust
interface: VL30_iot
action address family protocol src des description reject
IPv6
any
any
any
:any
reject everything IPv6 from VL30_iot
pass
IPv4
udp
VL30_iot net
127.0.1.1
:NTP (123)
port forwarding of NTP from VL30_iot to pfSense
pass
IPv4
tcp/udp
VL30_iot net
127.0.1.1
:DNS (53)
port forwarding of DNS from VL30_iot to pfSense
pass
IPv4
tcp/udp
VL30_iot net
!
Network
=192.168.0.0
/16
:any
allow VL30_iot access to anything but the local network (the internet)
reject
IPv4
any
any
any
:any
reject everything else IPv4 from VL30_iot
interface: VL40_guest
action address family protocol src des description reject
IPv6
any
any
any
:any
reject everything IPv6 from VL40_guest
pass
IPv4
udp
VL40_guest net
127.0.1.1
:NTP (123)
port forwarding of NTP from VL40_guest to pfSense
pass
IPv4
tcp/udp
VL40_guest net
127.0.1.1
:DNS (53)
port forwarding of DNS from VL40_guest to pfSense
pass
IPv4
tcp/udp
VL40_guest net
!
Network
=192.168.0.0
/16
:any
allow VL40_guest access to anything but the local network (the internet)
reject
IPv4
any
any
any
:any
reject everything else IPv4 from VL40_guest
One thing I am unsure of is if I need my reject rules. In theory, shouldn't it reject everything that doesn't match a previous rule?
-
You can't use 127.0.0.1 as a destination in a lan firewall rule. Its pointless
Use this firewall instead
And what do you mean by port forwarding of ntp from vlan to pf?
You are not natting anything inside your vlans, are you? -
@netblues said in Need help with my VLAN firewall rules to make sure they do what I think they do:
You can't use 127.0.0.1 as a destination in a lan firewall rule. Its pointless
What do you mean? The pfSense guide has it: https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html. When I add that port-forward it will auto-create the FW rule and I can't edit the destination.
@netblues said in Need help with my VLAN firewall rules to make sure they do what I think they do:
And what do you mean by port forwarding of ntp from vlan to pf?
I want all NTP and DNS queries from any VLAN to be sent back to my pfSense box to handle them.
@netblues said in Need help with my VLAN firewall rules to make sure they do what I think they do:
You are not natting anything inside your vlans, are you?
Uh, not that I know of?
-
But I am having an issue. On my Windows machine (the only one I've tested so far), when I try to go to a site, it does a DNS query on the VLAN gateway. So if I am on the machine
192.168.10.100
, the DNS query goes to192.168.10.1
. But since I don't have any FW rule or redirect to handle that, it fails. The redirect says anything but192.168.10.1
.Is my configuration wrong? What do I need to fix?
-
@imthenachoman Ah, I didn't get you were trying to redirect dns to pfsense in the first place.
Have you verified that normal dns resolution works using pfsense lan address as a resolver from your windows client?
You do have to allow dns requests (udp/tcp) to reach the configured lan interface address on pf.
-
I have not read all the above (rules) , and am not using DNS redirect. My guess is it happens like this.
The pfSense "redirect" would "catch all" traffic destined for port XXX (here 53/123) , and reroute it to the pfSense IP dest. 127.0.0.1 (localhost).
This would mean that pfSense would handle (answer) those requests.But in order for the request packet to be processed at all , you will have to allow it to enter the interface via a fw rule.
I'm only allowing DNS requests to "TFW" (this firewall) , meaning all pfSense interfaces , and have the pfSense IF set as DNS in all my DHCP definitions. If my clients try to ask another DNS ip , the package would be blocked.
But with your redirect setup (more elegant), i would expect that you can allow DNS to "any" in the firewall rule. As the redirect should catch all requests , and redirect them to he pfSense (localhost). And the client using a "foreign" dns , will still get an answer (from pfSense).
So you need two rules.
1: Allow DNS to enter via the interface.
2: Firewall redirect rule/Bingo
-
@netblues said in Need help with my VLAN firewall rules to make sure they do what I think they do:
Have you verified that normal dns resolution works using pfsense lan address as a resolver from your windows client?
I don't follow. From what I can tell, even on the default LAN interface, Windows was using
192.168.1.1
as the DNS server and ergo not redirecting DNS queries back to pfSense because the redirect rule says! LAN address
and192.168.1.1
isLAN address
.You do have to allow dns requests (udp/tcp) to reach the configured lan interface address on pf.
Yes, isn't that what the port forwarding rules are? Those were addedautomatically when you add the redirect rule.
-
@bingo600 said in Need help with my VLAN firewall rules to make sure they do what I think they do:
The pfSense "redirect" would "catch all" traffic destined for port XXX (here 53/123) , and reroute it to the pfSense IP dest. 127.0.0.1 (localhost).
Yes but the issue is it's not. The redirect rule, per the instructions on the pfSense site, says to redirect all :53 traffic that is
not
interface address
. However, Windows is sending DNS to the interface gateway which is theinterface address
. -
I have not looked to closely at these rules.. But lot of them make no sense.
Why do you have block on wan? This is the default, there is not reason for those rules.
Also if your trying to redirect traffic for dns/ntp, why do you have 127.0.1.1 vs 127.0.0.1?
Other rules make no sense either. You have a "antilockout" rule listed to allow 22 to vlan20 address - when does ssh use UDP? But then you also have a rule allowing 22 to the dmz address? What is the point of that, ssh to pfsense vlan20 address is the same thing as ssh to its dmz address.. Did you mean dmz net?
Also you have a reject any any at the end? Why default is deny, there is no reason for that rule at the end? Do you specifically want to send a reject vs just drop? If so that ok that rule could have value. You understand the difference between reject and block right?
Same goes for all your ipv6 rules.. Deny is the default - there is no reason to put those rules in, if there is no allows for it anyway. Are you wanting to log or not log some of this traffic.. You don't state which rules are listed as logging or not logging..
Seems like you went to a lot of trouble to post up those rules in such a way.. with the markup and all.. But its not every easy to look at...
Would of been easier to just post up screenshot of the actual rules - including your port forwards.
From the way you posted those rules - I don't see how dns would work since your trying to redirect it to something that will not answer.. 127.0.1.1
Also ! rules, or inverse rules can be problematic if you have any vips setup, etc. I would suggest you use explicit deny rules..
-
@johnpoz said in Need help with my VLAN firewall rules to make sure they do what I think they do:
...
The
127.0.0.1
is a typo. It should be127.0.0.1
.You're right on the reject rules. This is my first time playing around with FW rules and I wasn't sure at first. I've cleaned my rules up.
when does ssh use UDP
My mistake. Will fix.
But then you also have a rule allowing 22 to the dmz address? What is the point of that
I want all devices in VL20_trust to be able to SSH to devices in VL10_dmz. But ignore that rule for now. I haven't actually added it cause I'm trying to get the other rules to work first.
Right now I am trying to make it so client DNS queries all go through pfSense. And they sorta are, but not how I expect.
Looking at just my current
LAN
rule I created a redirect as mentioned here: https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html. My understanding of the rule is:- traffic on
LAN
- going to anywhere
not
LAN address
on port53
- redirect to
127.0.0.1:53
(pfSense)
But the client is getting
LAN address
(192.168.1.1
) as the DNS server so it is sending its DNS queries tointerface address
(192.168.1.1
). Ergo, the port forward rules don't get triggered.Below is picture of my port forward rule and
LAN
FW rules. No traffic is going to theLAN
DNS
rule.I followed the instructions in the recipe so I am not sure what is wrong. Is there something else I need to be doing? I feel like I am missing a step that is supposed to make it so DNS queries on LAN/VLAN address (like
192.168.1.1
) also go to127.0.0.1:53
? - traffic on
-
If your lan address is 192.168.1.1 on pfsense, that redirect would not come into play... Your port forward says if NOT lan address (192.168.1.1)
But your sending dns queries to 192.168.1.1..
If you want to test that rule, send directed dns query to say 8.8.8.8 or something..
-
I see. So the clients use the LAN/VLAN address as the DNS server. What do I need to do to make sure the DNS queries clients send, to the LAN/VLAN address, also get routed to 127.0.0.1? Another port forward rule?
-
@imthenachoman said in Need help with my VLAN firewall rules to make sure they do what I think they do:
I see. So the clients use the LAN/VLAN address as the DNS server. What do I need to do to make sure the DNS queries clients send, to the LAN/VLAN address, also get routed to 127.0.0.1? Another port forward rule?
How about changing from !LAN to "Any"
-
@imthenachoman said in Need help with my VLAN firewall rules to make sure they do what I think they do:
o the LAN/VLAN address, also get routed to 127.0.0.1? Another port forward rule?
what would it matter? They are going to the same place to be honest. They are still going to unbound be it loopback or 192.168.1.1 - still going to unbound.
-
Thanks. I was thinking that but then unsure since the pfsense recipe didn’t say that. I kinda assumed the recipe instructions would do what I need/expect — assuming it was written with the understanding that clients would get LAN IP as DNS server.
-
But the port forward rule says to forward anything NOT to the LAN IP. Since the clients are using the LAN IP as DNS server, the port forward rule never triggers. Or am I misunderstanding?
-
The forward rule is a "Catch any" and redirect to 127.0.0.1 (that's the pfsense).
The only thing not "Caught" is the DNS going directly to the LAN interface ... Who/what do you think handles the requests on the incomming Lan interface ??
/Bingo
-
I see. So I guess I need a FW rule to allow clients to access LAN address. I don’t think I have that right now. :/
-
EUREKA!
So I had to add another FW rule that says allow IPv4 TCP/UDP from LAN net to LAN net on 53. I can see that rule working.
Thanks all!
-
@imthenachoman said in Need help with my VLAN firewall rules to make sure they do what I think they do:
I don’t think I have that right now. :/
yeah you do
That rule allows anything - if there was not a specific deny above that - then it would be allowed.
Rules are evaluated top down. first rule to trigger wins, no other rules are evaluated. So if your trying to talk to 192.168.1.1 on 53 you have no rules above that any any rule that would block that or force it elsewhere - so its allowed. by your last rule.
-
Yes but it wasn't doing what I was expecting.
I would have expected the FW rule I circled (the
port forwarding of DNS from LAN to pfSense
) to be triggered. But it wasn't and so the catch all rule was catching it.But I figured out the issue and created a FW rule to allow traffic from LAN net to LAN net on 53. That rule is triggering for the client DNS queries -- so I don't need the catch all.
Not that you asked, but if you're curious, I've been making notes for myself and decided to put it in a public gist to hopefully help others out. https://gist.github.com/imthenachoman/67ca5f0cb747b680ca4a44abdc564b20
-
@imthenachoman said in Need help with my VLAN firewall rules to make sure they do what I think they do:
FW rule to allow traffic from LAN net to LAN net on 53.
Rule doesn't make a lot of sense.. If you want to allow access to lan address, then allow that.. lan net as destination on the lan interface makes no sense..
Lan can already talk to anything else on the lan, devices on lan don't talk to pfsense to talk to other stuff on lan. So lan net as destination makes no sense on the lan interface. Lan address is a destination that makes sense, stuff other than lan make sense..
We already went over why your circled rule wouldn't match..
Not sure where you got the idea that everything needs to be redirect to pfsense. Are you not handing them already.. If you don't want things talking to other than pfsense for dns or ntp. Block it I think is better.
Would you like it if your isp said, hey you know what we don't want clients using google - so lets redirect them so they think they are talking to google, but they will really be talking to us.
Redirection can be a solution to a problem - where client X doesn't listen to what you you hand him via dhcp, or set on him directly.. Personally I think its a bad idea to do as some sort of standard.. I would say a block rule is prob better than you log, so you can see hey this client I hand pfsense for dns, why does he continue to bang his head trying to query google for xyz.tld..
-
I want to have very tight control of what traffic is allowed where. I don't want any kind of "default allow all" rule or anything.
Lan can already talk to anything else on the lan, devices on lan don't talk to pfsense to talk to other stuff on lan. So lan net as destination makes no sense on the lan interface. Lan address is a destination that makes sense, stuff other than lan make sense..
So, my understanding is,
LAN net
is192.168.1.1
, right? That is also what clients onLAN
get for the DNS server. So when said clients want to do a DNS query they send it to192.168.1.1:53
. Am I right so far?So if I want traffic from the
LAN
clients coming throughLAN net
to be able to make DNS queries to192.168.1.1
:53
, orLAN net
:53
, then I need a FW rule saying traffic fromLAN net
toLAN net
:53
is allowed. Right?Not sure where you got the idea that everything needs to be redirect to pfsense.
Why is it not better to have a central authority for all DNS queries on my network? That way those queries are cached. So if
system1
looks upexample.com
, whensystem2
looks it up, pfSense can return a cached response. Isn't that good/desirable? -
I wager most folks disagree with me for having excessively strict rules. I'd be willing to debate/discuss it with someone but I much prefer the policy of only allowing exactly what is needed, nothing more, nothing less.
-
LAN address is the address of the interface of the pfSense to the LAN. (ie. 192.168.1.1/32)
LAN subnet is the subnet attached to this interface. (ie. 192.168.1.0/24)As for caching of dns, well, unbound is bound to all running interfaces, so this will happen by default, without any redirects.
If you are using pfblockerng, then yes, you probably want some control over external dns access
Having total control is nice, but it also means to be constantly adjusting things.
Its nice as an exercise, but doing that in a home network with demanding users (aka kids) is kinda of a full time job. -
@imthenachoman said in Need help with my VLAN firewall rules to make sure they do what I think they do:
So, my understanding is,
LAN net
is192.168.1.1
, right? That is also what clients onLAN
get for the DNS server. So when said clients want to do a DNS query they send it to192.168.1.1:53
. Am I right so far?So if I want traffic from the
LAN
clients coming throughLAN net
to be able to make DNS queries to192.168.1.1
:53
, orLAN net
:53
, then I need a FW rule saying traffic fromLAN net
toLAN net
:53
is allowed. Right?Re: Lan net vs Lan address (pulldown selections)
Lan address is the specific interface adresss : ie. 192.168.1.1
Lan net is the defined network : ie. 192.168.1.0/24For allowing any (on the Lan) to send DNS req. to the interface i would do.
IF : LAN
AF: IPv4
Proto: TCP/UDP
SRC: Lan net
Dest: Lan address (Only matches The interface ip)
Port: DNSAllow Lan Net to Lan Net , would only be effective if the dest-ip was the Lan interface, as all other packets sent between devices on the same "subnet" would be sent directly between the devices. And not pass the firewall. Hence the rule would be better indicating : LanNet to Lan address (interface ip)
Btw: I totally agree with @netblues , that only allowing specific permits , on a "general use" subnet. Would be a steady job.
-
Btw:
Only allow DNS requests to "Lan address" seems a bit contradictive , with the purpose of the "DNS forward rule".The forward rule (Catch all DNS) , is usually made in order to catch programs/apps that uses "hardcoded" or custom DNS servers. Ie. a Google app that tried to resolve DNS via 8.8.8.8.
If DNS to "any" was allowed (while the DNS forward rule was in place) , the request to 8.8.8.8 would be rewritten to 127.0.0.1 once the package was entering the pfSense , and the APP would still get a DNS answer (from pfSense).
If you only allow DNS to the LAN address (interface) the request to 8.8.8.8 would just be dropped.
It depends on what you want .....
I only allow DNS to my "interface" , and all(most) all apps that tries a "foreign" DNS , will fall back to the DNS given by DHCP.
But it will break Ie. PI-Hole updates , as they now relies on SRV records from a specific DNS server , to inform about supported OS'es. And the forward "trick" would also break it.
I think i have 2..3 apps that are misbehaving if not allowed to their native DNS. I can live with those limitations.
/Bingo
-
@bingo600 said in Need help with my VLAN firewall rules to make sure they do what I think they do:
as they now relies on SRV records from a specific DNS server
huh/what?? That is not how it works..
Your saying pihole has to talk to a specific NS or it can't update??
-
Not saying you can not stop something from talking to DNS you don't want it to - my point is redirection of traffic hiding from the client that it not talking to who it thinks it is talking to is not good practice.
You sure and the F would not like it if your isp did it to you.. While its your network and you can do what you want. It amounts to the pot calling the kettle.
If you don't want something talking to outside dns, then block it sure.. But redirection is not good idea if you ask me..
-
@johnpoz said in Need help with my VLAN firewall rules to make sure they do what I think they do:
@bingo600 said in Need help with my VLAN firewall rules to make sure they do what I think they do:
as they now relies on SRV records from a specific DNS server
huh/what?? That is not how it works..
Your saying pihole has to talk to a specific NS or it can't update??
Yup
https://github.com/pi-hole/pi-hole/issues/3694Somehow it won't (in default config) accept my DEB10 as a valid OS , unless i permit access to : ns1.pi-hole.net / 185.136.96.96 (for Update)
A workaround would be this : PIHOLE_SKIP_OS_CHECK=true
So DNS is being (mis)Used for lot's of tricks.
And it is how it works (for pihole update)
Edit:
pihole-check Git commmit
https://github.com/pi-hole/pi-hole/commit/0ff32c3629220f386a45c14d8982aaaf128aa47fI didn't dig deeper , as i just did a temporary permit during the update.
Edit2: Seems to be a TXT not SRV (my bad)
/Bingo
-
Yeah I agree with the comments on that - that is a HORRIBLE solution to an issue of some local dns sucking..
Looks like they are changing it to output info, for those that block dns..
Since when does MS dns fail to return txt records? I don't see any SRV mentioned in that?
-
@johnpoz
My bad assumed they used a SRV not a TXT -
My main dns'es are two local bind9 servers.
Everything else , including pihole & unbound uses thosePrimary reason i had them running before pfSense was installed.
Use them for DNS & DHCP , and get the full ISC features.And i can do dynamic DHCP updates wo. the dreaded unbound dead time
-
My pihole is currently up to date..
root@pi-hole:/home/pi# pihole -up [i] Checking for updates... [i] Pi-hole Core: up to date [i] Web Interface: up to date [i] FTL: up to date [✓] Everything is up to date! root@pi-hole:/home/pi#
But I will for sure try and test this next time an update is out.. I have just added a block any other dns on the piholes vlan.. I was blocking dot and doh.. It didn't attempt to check any other dns when I asked it to see if update - but maybe it only does that if there is an update?
-
@bingo600 said in Need help with my VLAN firewall rules to make sure they do what I think they do:
Re: Lan net vs Lan address (pulldown selections)
Lan address is the specific interface adresss : ie. 192.168.1.1Oh! I see my mistake now.
Lan net is the defined network : ie. 192.168.1.0/24
For allowing any (on the Lan) to send DNS req. to the interface i would do.
IF : LAN
AF: IPv4
Proto: TCP/UDP
SRC: Lan net
Dest: Lan address (Only matches The interface ip)
Port: DNSAwesome. Thank you!
@bingo600 said in Need help with my VLAN firewall rules to make sure they do what I think they do:
If DNS to "any" was allowed (while the DNS forward rule was in place) , the request to 8.8.8.8 would be rewritten to 127.0.0.1 once the package was entering the pfSense , and the APP would still get a DNS answer (from pfSense).
Wouldn't a port forward rule take care of this? Any request from a client on
:53
gets redirected to127.0.0.1
(pfSense)?@johnpoz said in Need help with my VLAN firewall rules to make sure they do what I think they do:
Not saying you can not stop something from talking to DNS you don't want it to - my point is redirection of traffic hiding from the client that it not talking to who it thinks it is talking to is not good practice.
Totally fair. But as I am just starting out in my journey, I will set it like this for a while and see how ti works. I'll redo everything in a few months anyway -- once I understand things better -- and then I'll see how I set up my DNS.
--
I really do appreciate all of the time y'all have been putting in to help me. I am a big fan/supporter of paying those who help when I can. Teachers in schools get paid, so should teachers elsewhere. LMK if I can return the fair monetarily.
Also, Happy Holidays everyone!
-
I have localhost as resolver on the pihole DEB10
dns-nameservers 127.0.0.1And pihole is using my bind9's as upstream resolvers (on the same L2) - That failed during the updates.
Then i made a specific allow pihole/32 to any - dns
And it updated.After update i disabled that one again
-
@imthenachoman said in Need help with my VLAN firewall rules to make sure they do what I think they do:
LMK if I can return the fair monetarily.
My (adequate) payment is to know i helped someone else that has an issue. - We have all been there.
And i hope they will help someone else in the same way.Also, Happy Holidays everyone!
You too
Edit: There is an implicit "thank you" method here on the forum.
Click the "Thumbs up icon" in the bottom of the post you like.
That gives the poster a +1 on helpfull posts./Bingo
-
I have been a naughty boy
And hadn't updated mine.Here's a "sniff" of my pihole ip , w. port 53 tcp/udp during a "NS1 allowed" update.
Wo. allowing "NS1" it barfs.
/Bingo -
Why are they doing a directed query? What reason is given - that AD or MS dns does not allow for TXT queries? That is utter BS plain and simple..
I am not buying the reason for doing this at all..
-
@johnpoz
I don't have anything w M$ DNS
If you do you could try the dig they use here.https://github.com/pi-hole/pi-hole/commit/0ff32c3629220f386a45c14d8982aaaf128aa47f
If working it should give the same answer as in my sniff above i suppose.
Or the pcap here