Rules to allow Homekit across vlan
-
I had to power cycle my pfS box and WAP today (was doing cable management...)
When everything came back up all my HomeKit devices were on wifi, but the Home app reported them as all offline.I had to reenable my ANY rules and move them to the top of my ruleset in order to get everything back. When I had them enabled but at the bottom of the list a few devices kept randomly dropping.
This is pretty obvious evidence that there are some other ports/protocols that need to be allowed for a happy HomeKit experience.
Here's a pic of my full set of rules, can anyone tell me what might be missing?
-
@tknospdr said in Rules to allow Homekit across vlan:
I had to reenable my ANY rules and move them to the top of my ruleset in order to get everything back.
I would check your firewall logs for the things that are blocking them from communicating. I have no issues here but I also have limited HomeKit items and don't mind them being able to talk to many things.
Don't ask my other IoT devices what I think of them, though, they will hear you, reply, but they can't seek you out
-
@rcoleman-netgate
I've never parsed the logs in pfSense before.
What would I be looking for?I checked out the logs and they're quite full of deny statements (obviously), how do I narrow down the scope of what I'm looking at?
-
@tknospdr Check for the IP of your device(s). Click the funnel (sieve) icon on the top to filter the logs.
https://docs.netgate.com/pfsense/en/latest/monitoring/logs/index.html -
Looks like the FW logs only keep the last 500 transactions.
I guess all the relevant entries fell off the bottom.
I got zero results for multiple IP addresses connected to IoT/HK devices that I know weren't responding.
Looks like I'll have to disable my any rules again and wait till things break once more.The odd thing is I think they continue to work unless the wifi or power goes out, THEN they have issues reconnecting. So it might be some sort of initial handshake that's being rejected.
Shouldn't take too long, the power company is moving my whole city's lines from overhead to underground so our power has been doing weird crap for the past few weeks.
-
@tknospdr said in Rules to allow Homekit across vlan:
Looks like the FW logs only keep the last 500 transactions.
You can edit that
-
Odd, I upped it to 3000 entries and searched for the IP address of my garage door opener which I specifically remember was not connecting to the home app.
There were no hits on it...
-
@tknospdr did you enable logging on pass rules? By default pfsense doesn't log allow rule traffic, only default deny.
Do you see the 5353 mdns traffic? That would be multicast destination.. I have a couple of threads around here about troubleshooting avahi.. And what rules you have to have to allow it to work.. and via sniffing validate that your traffic is being sent on, etc.
here is one of my troubleshooting avahi posts
https://forum.netgate.com/topic/166642/mdns-struggles/11?_=1691526954616
-
@johnpoz said in Rules to allow Homekit across vlan:
@tknospdr did you enable logging on pass rules? By default pfsense doesn't log allow rule traffic, only default deny.
No, but I thought I was looking for deny rules as I'm trying to TS broken connections.
Do you see the 5353 mdns traffic? That would be multicast destination.. I have a couple of threads around here about troubleshooting avahi.. And what rules you have to have to allow it to work.. and via sniffing validate that your traffic is being sent on, etc.
I see hundreds of these and I don't recognize either of the IP addresses, but I'm thinking they may be multicast addresses?
Aug 8 14:07:13 ETH3 Block IPv4 link-local (1000000101) 169.254.1.1:5353
Cannot resolve 224.0.0.251:5353
Cannot resolve UDPhere is one of my troubleshooting avahi posts
https://forum.netgate.com/topic/166642/mdns-struggles/11?_=1691526954616
I will read over this thread and see what I can grok.
-
@tknospdr said in Rules to allow Homekit across vlan:
169.254.1.1:5353
Not sure how that would do anything - that is a APIPA address, ie link local for single network.. It wouldn't route across pfsense anyway. Even if it got back an answer from its discovery of something that was on 192.168.x.x etc..
A 169.254 is something normally gives itself when dhcp doesn't work.. It could for something discovery something on the local network - I think one of my directv bridge device things use to send out SSDP from that IP range, etc.. But its pretty much just noise..
I think there is a way to get 169.254 to be routed - I think there is check box in pfsense somewhere to allow that.. But that would not really be a solution to be honest.
-
I read through the thread you referenced. Most of it is above my head as I've had no experience with sniffing and doing packet captures etc. I need someone to hold my hand one day and show me the how's and why's to do these things.
What I did get out of it was your screen cap of the floating rule to allow MDNS traffic to cross boundaries. I added that to my floating tab, and then disabled the ANY rules in ETH3 (my LAN with all the IoT stuff).
We shall see how it goes. -
@tknospdr the rules and avahi settings are the import pieces in that thread - the sniffs to was see if it was actually doing what it is suppose to do, and still having problems.
The "sniff" is just a packet capture under diagnostics menu..
The way avahi works is its sees the discovery, ie the traffic to the multicast address (means everything on that network sees it) to port 5353 (mdns) and forwards that to the other network you setup in avahi, like it came from pfsense IP address in that network.
If something on that network wants to answer the discovery - oh hey I have a printer you can use, or some other kind of service it answers back to pfsense IP... Pfsense says oh hey there is this service... Let me send that back to the guy who actually asked me on the source vlan.
See in that post where in the sniff it says my printer is on the 192.168.2.50 IP..
-
2 of my devices just went offline.
Do I just search for them in the FW logs to see what is being denied to them?500 of these:
Aug 8 20:11:57 ETH3 Default deny rule IPv4 (1000000103) 10.100.10.217:33971
Meross-Smart-Bulb.technospider.com 10.100.10.1:53
Cannot resolve UDPAnd 500 of these:
Aug 8 20:14:19 ETH3 Default deny rule IPv4 (1000000103) 10.100.10.228:28115
Cannot resolve 10.100.10.1:53 UDPWhy is it being denied talking to the interface?
-
@tknospdr said in Rules to allow Homekit across vlan:
Why is it being denied talking to the interface?
Do you have a rule on 10.100.10.1 interface on pfsense to allow 53 (dns)..
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.11 | Lab VMs 2.7.2, 24.11 -
Something like this:
️ -
Do you have a rule on 10.100.10.1 interface on pfsense to allow 53 (dns)..
Good point, I was tired last night and my eyes saw 5353, not just 53.
-
@RobbieTT said in Rules to allow Homekit across vlan:
Something like this:
️Is there an effective difference between choosing 'this firewall' VS 'ETH3 address' for this rule?
-
@tknospdr yeah this firewall would allow access to any and all pfsense IPs, and the eth3 address would only allow access to the eth3 address.
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.11 | Lab VMs 2.7.2, 24.11 -
@johnpoz Not really. In the above example it can resolve DNS requests on the port listed using TCP/UDP. It does not give the VLAN access to all addresses.
️ -
@RobbieTT said in Rules to allow Homekit across vlan:
TCP/UDP. It does not give the VLAN access to all addresses.
It does on port 53.. That rule says you can go to any IP on pfsense on port 53..
https://forum.netgate.com/post/708897
"This Firewall (self)" does what it says – It's every address on the firewall already. It's a pf macro that refers to the firewall host and any address it has, collectively.
