Setting up for Wyze cam base station
-
I have a Wyze security cam setup but their little base station connected by ethernet to my network that controls two cameras is always shown as offline and because of this, notifications based on motion detection does not work. I'm sure I have to add something to pfsense to allow this connection but Wyze has no info and I don't know where to start as I haven't had to do anything for the rest of my hardware. Not even sure I've picked the correct forum.
-
@lucas-0 It will be difficult for anyone to help with the little bit of information you have given.
-
Does the Wyze base station show in the pfsense ARP Table as having an IP address assigned to it?
-
Does Wyze base station's interface show that is has an IP address?
-
Is the Wyze base station able to reach the DNS server?
-
Have you plugged something else into the ethernet cable the Wyze base station is plugged into to verify the physical connection is working as expected?
-
Do you have pfBlocker or some other package blocking the Wyze base station from reaching its destination address?
-
What do the floating, group, and interface firewall rules on the interface the Wyze base station is plugged into look like?
-
-
Shown in the ARP Table.
Static IP assigned outside of DHCP.
But base station shows as permanently Offline in Wyze app.
Not sure how to test that other than DNS Diagnostics for static IP. Pings successfully as well.
pfBlockerNG enabled.
-
@lucas-0 The pfBlockerNG reports tab will show you if it is blocking traffic from the Wyze base station IP address.
Is your Wyze base station's IP address 192.168.11.30?
-
@hieroglyph Yes.
-
Firewall rules are parsed from the top down.
your block all to port 53 superscedes the last rule that allows any to 127.0.0.1 which really.. does nothing anyways.
But it also kills anything to port 53 out to the internet for any IOT device that has its DNS hard coded. Some devices just will refuse to use any DNS besides their own.
Put an allow rule up top and see if it starts working.
-
Your source should just be "LAN Net" for every rule.
any other address just doesn't belong and wouldn't be routed on that interface anyways.
-
I see an issue with how your DNS rules are ordered for LAN.
In the LAN firewall rules you have x3 rules filtering for DNS. Because the names of x2 of the rules are exactly the same I will use relative positions. They are the 3rd, 4th, and 9th rules.
The 3rd rule: Passes all traffic on the LAN interface destined for 192.168.11.1 on port 53. This rule looks good.
The 4th rule: Any DNS traffic not passed by the 3rd rule will match the 4th rule. Meaning, all traffic on the LAN interface not destined for 192.168.11.1 on port 53 will be blocked. Meaning any device with a hard coded DNS IP will have no way of contacting a DNS server.
The 9th rule: Is the NAT redirect rule that should take traffic on the LAN interface not destined for 192.168.11.1 on port 53 and redirect it back to the routers 127.0.0.1 internal address. This rule will never match anything because the 3rd rule says pass DNS traffic destined to 192.168.11.1 and the 4th rule says to block anything not destined to 192.168.11.1.
The 9th rule needs to be above the 4th rule.
Your WAN firewall rules show you have opened up port 36330 to the outside world, the rule named "Folding At Home". Any "hacker" out there scanning ports will see port 36330 is open on your machine. Make sure you need port 36330 open on the WAN interface.
Same for the rule named "NAT Wyze Base Station". Everyone in the world will be able to access your Wyze Base Station the way you have this set up. If you need to access this device when you are not home, I recommend setting up a road warrior VPN via OpenVPN to securely access your home network when you are not home. There are plenty of tutorials out there.
The Floating firewall rule... why is it there? All traffic coming in from WAN will be blocked by default unless pass rules are setup to allow incoming traffic to port 53. I do not see any pass rules for port 53 in your WAN firewall rules. Not to mention you are "rejecting" on the WAN instead of "blocking". Unless you are double NAT'd (which your WAN rules say you are not) and need to "reject" for some reason. It is best to use "block" for all WAN rules. Read this to understand why: https://docs.netgate.com/pfsense/en/latest/firewall/fundamentals.html#block-vs-reject
In your WAN firewall rule it shows an opt1 interface. But I do not see an opt1 interface as an optional tab to select in the firewall rules shown. IDK what that may do especially because it tied to a WAN rule. But you may want to review your floating rule. From what I see, it should be deleted.
If you have not already; read: https://docs.netgate.com/pfsense/en/latest/firewall/fundamentals.html
-
This post is deleted! -
@chpalmer Beat me to it
-
-
@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. -
127.0.0.1 is not a routable address. No reason for that rule. Notice the bit count. 0/0.
-
@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?
-
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.
-
@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):
-
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. :)
-
@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!
-
@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.htmlThat 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.
-
@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.
