Setting up for Wyze cam base station

[hieroglyph]

@chpalmer Beat me to it

[Lucas 0]

[hieroglyph]

@lucas-0 In the LAN firewall rules, the NAT rule was fine. It did not need to be disabled. It needed to be moved above the second "Blocking DNS Queries To External Resolvers (Netgate)" block rule.

What you have done with the Wyze Base Station rule is make is so any device on the LAN interface can contact the Wyze Base Station (192.168.11.30) on port 53. This does not help the Wyze Base Station itself contact DNS on port 53.

Again, move and enable the "NAT Redirect DNS" rule above the second "Blocking DNS Queries To External Resolvers (Netgate)" block rule. Then delete the "Wyze Base Station" rule.

Please do read this: https://docs.netgate.com/pfsense/en/latest/firewall/fundamentals.html
It give the basic information needed to write firewall rules in a way that makes sense.

[chpalmer]

@hieroglyph

127.0.0.1 is not a routable address. No reason for that rule. Notice the bit count. 0/0.

[hieroglyph]

@chpalmer I am still learning so you may be right. When I look at my own auto-created NAT redirect rule for DNS I see bit count for the rule with the 127.0.0.1 address. Have I messed up something with my DNS redirect and/or created some kind of DNS leak?

[chpalmer]

@hieroglyph

Without seeing everything else in your setup it is hard to tell. The internal workings of the firewall are not affected by interface firewall rules (rules affect traffic as it comes into an interface).

pfsense will use 127.0.0.1 when it contacts its own DNS so you probably have that count somehow.. Im not sure how though.

[hieroglyph]

@chpalmer I see what you are saying. Traffic already inside of the firewall would be unaffected by the interface rules.

It is strange though, when a NAT Port Forward rule is created an associated firewall rule is also created by default. As described here under the "Filter Rule Association" setting: https://docs.netgate.com/pfsense/en/latest/nat/port-forwards.html#adding-port-forwards

Filter Rule Association

This final option is very important. A port forward entry only defines which traffic will be redirected, a firewall rule is required to pass any traffic through that redirection. By default, Add associated filter rule is selected. The available choices are:

It goes on to describe different setting choices of None, Add associated filter rule, Add unassociated filter rule, and Pass.

Is what you are describing something that needs to have the "Filter Rule Association" setting in the NAT Port Forward rule set to a value of "Pass" so the traffic is passed thru without the need of a firewall rule?

My Nat Port Forward Rules For DNS and NTP:

The Automatically Created Firewall Rules (Descriptions start with the word NAT):

[chpalmer]

@hieroglyph

My Nat Port Forward Rules For DNS and NTP:

Port forwards are for traffic coming in on the other side of NAT such and would generally only be on the WAN. Since all incoming traffic on the WAN by default is blocked the associated rule must be there to allow that traffic.

pfSense itself is a router. Any LAN type interfaces (no matter what you name them) will route to each other. I can easily connect to my server interfaces or even my voip interfaces from my desktop here. The default "to any" setting on my LAN firewall rule allows that. I can (and do) however block my servers, VOIP, IOT ect interfaces from seeing my LAN or any other interface except to go out to the WAN. Long story short.. there is no reason to try and port forward from one LAN interface to another.

When doing a port forward I would either choose None (and then build the rule myself which is my default) or "Associated Filter Rule" (which will build the rule but have limited editing capability for you)

Im not sure what you are doing with DNS but unless you are running an internal DNS on one of your interfaces that is available to the outside world I would question why you need any port forwarding at all for DNS.. Allowing outside (WAN) access to your pfSense DNS would only take a firewall rule (and if you do not know what your doing would be considered risky behavior)

First and foremost remember that pfSense is a router. Firewall rules would be used to control traffic for your routed traffic. Traffic that is initiated will be able to return without the need of a "return" side firewall rule allowing it. The firewall is "Stateful". Once the state is opened from one side the connection can go back and forth as long as the state remains open. I have no need to have any firewall rule on my "Server" interface in order for my servers to respond to outside traffic. (Only reason for any server rule is so the servers can access the outside world for their own purposes such as update checks and NTP, ect..)

Traffic on the same network meant for another device on the same network will never touch your pfSense. (If you have DNS on an internal server and other clients are on that same interface they will go direct to that server.)

It does look like you are getting hits on your 127.0.0.1 address but Im unsure why.

Hope I didn't ramble to much but maybe there is a tidbit above you were unaware of..??

Back to getting wet in the rain for me. :)

[hieroglyph]

@chpalmer Lol, not too much ramble. I was able to read it all the way thru.

I used these two pfsense guides to make sure all DNS requests generated by devices on LANs are handled by the pfsense unbound DNS resolver. And cannot be sent directly to external DNS resolvers (e.g. 8.8.8.8).

https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html

https://docs.netgate.com/pfsense/en/latest/recipes/dns-block-external.html

At the end of the first guide it says:

If DNS requests to other DNS servers are blocked, such as by following Blocking External Client DNS Queries, ensure the rule to pass DNS to 127.0.0.1 is above any rule that blocks DNS.

Once seeing @Lucas-0's DNS rules I operated under the assumption they followed the same guides. I was wrong to make that assumption. I should have asked if they followed these guides before assuming it was the direction they were trying to go.

It has been raining all day over my way too. Stay safe out there in this cold and wet weather!

[chpalmer]

@hieroglyph said in Setting up for Wyze cam base station:

ensure the rule to pass DNS to 127.0.0.1
https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html

That is the first time I have ever read that particular document.. Not sure why 127.0.0.1 instead of "This Firewall" or the interface address itself.. ??

If you have allow to any then 127.0.0.1 would be allowed. Adding a rule before "allow any" would allow you to count the bits. But that is about it.

That doc seems like a wild back door way of doing it but I guess we all learn something new sometimes.

[hieroglyph]

@chpalmer Cool. Good to know I was not doing something too far out of the park.

I went back into my NAT rule to see if I could change it to "This Firewall". It looks like the Redirect Target IP is a textbox. Typing into it will show compatible aliases. But when trying to type "This Firewal", "Firewall", or "Self" there was no compatible choice. I am thinking this is why the guide suggests using 127.0.0.1.

@Lucas-0 Apologies, for taking this off on a tangent. Either of our methods will work. @chpalmer's method will allow you to do it in one less rule.

[Lucas 0]

@hieroglyph I managed to lock myself out and lose my network completely by making some change. I was able to restore a prior setup at the computer I have pfsense running. So I'm back to where I started. The few tweaks I tried on advice didn't change the off line status of the base station.

[Lucas 0]

@hieroglyph Well, I finally got it working by the last thing I tried: dragging the NAT rule above everything else

The links provided in this tread showed examples for DNS and NAT, but none I found that showed both, or mentioned order of precedence though I might easily have missed it.

Of course, I'm also not sure I've not set myself up for new and different vulnerabilities through this ruleset either. I'm wondering if there are tools to safely test a pfSense configuration.

I would like to place all such 'IoT' hardware on a VLAN, but reading and watching tutorials all seem to require a managed switch, which I don't have. Having one with POE for a Unifi AP is appealing but the costs aren't insignificant.

I today wondered about just placing IoT stuff on a different subnet, but wouldn't that also require establishing comms between the two subnets (port forwarding)?

[hieroglyph]

@lucas-0 Yep. That is how I have my rules ordered.

The x3 block rules for "HiddenWasp Linux Malware" will never be reached because they are below the two allow all rules (Default allow LAN to any rules) for IPv4 and IPv6. Same for the NORDVPN_VPNV4 rule. It will never be reached because LAN traffic will take the "Default allow LAN to any rules).

Rules are processed in a top to bottom order (with an exception of floating rules). I will not get into detail. But this is a good read to explain how to order rules.

If the pfsense box has at least x3 ports it could be set up as follows:

port1: WAN
port2: LAN --> Switch1
port3: LAN_IOT --> Switch2

This would give the same result as using VLANs to separate LAN from LAN_IOT. If LAN devices need to access LAN_IOT devices then a firewall rule will need to be put into place. Depending on how the IOT device is configured a NAT Outbound rule may also need to be put into place if the IOT device does not respond to IPs out of its IP address range.

For me, I just set up a generic NAT Outbound rule (allow LAN to LAN_IOT). The NAT rule does not do anything until there is a firewall rule setup which also allows (LAN.deviceX to LAN_IOT.deviceY). Don't be afraid to put pfsense into hybrid outbound NAT mode. It just moves the auto-generated rules to the bottom and allows the creation of custom rules.

But as always; before any changes are made to the pfsense box make sure there is recent backup configuration easily available for restoring in the event a mistake is made during the learning process.

Good luck and have fun!