Rules to allow Homekit across vlan

[johnpoz]

@tknospdr said in Rules to allow Homekit across vlan:

Looks like the FW logs only keep the last 500 transactions.

You can edit that

[tknospdr]

@johnpoz

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...

[johnpoz]

@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

[tknospdr]

@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 UDP

here 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.

[johnpoz]

@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.

[tknospdr]

@johnpoz

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.

[johnpoz]

@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..

[tknospdr]

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 UDP

And 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 UDP

Why is it being denied talking to the interface?

[johnpoz]

@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)..

[RobbieTT]

Something like this:

️

[tknospdr]

@johnpoz

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.

[tknospdr]

@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?

[johnpoz]

@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.

[RobbieTT]

@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.

️

[johnpoz]

@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.

[tknospdr]

@johnpoz said in Rules to allow Homekit across vlan:

@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.

I understand the difference, I was asking if in this particular case would it make a difference to the outcome of that rule to choose one or the other.

Anyway, here's my latest deny's, and what my current rules look like.

[johnpoz]

@tknospdr said in Rules to allow Homekit across vlan:

case would it make a difference to the outcome of that rule to choose one or the other.

No not really the "this firewall" would allow access to your eth3 address. But I wouldn't use the rule like that.. If your clients are going to use eth3 address as their dns, then that is what the rule should say. Why would they be using other IP on pfsense, other than the IP of pfsense in their network..

I use the this firewall in my rules as a reject when I don't want say my non trusted networks/vlans being able to access the web gui, etc. I have explicit rules to what specific networks are allowed to go to, and then block all other access to the firewall. the this firewall is good for that, along with an alias of rfc1918 networks in blocking networks/vlans from talking to your other networks/vlans.

Your dns rule there is set to tcp only - so yeah UDP would be blocked. DNS is almost always UDP.. TCP is a fallback, and used when whatever is going to be queried answer is too large for UDP.. That rule should be udp/tcp or if you just want 1 then it should be UDP.

Your rules on eth3 for 5353 are pretty pointless - those are going to be multicast.. And zero reason to let pfsense even see that traffic unless your going to be using avahi to pass it on to some other network. But the way those rules are written wouldn't be of any good.

your floating rule for 224.0.0.251 should allow your mdns via avahi.. But you could limit that rule down to 5353

edit:
keep in mind the 5353 with avahi would allow discovery, but your going to actually need a rule to allow whatever port(s) your service your going to actually be accessing once discovered.

[tknospdr]

@johnpoz said in Rules to allow Homekit across vlan:

Your dns rule there is set to tcp only - so yeah UDP would be blocked. DNS is almost always UDP.. TCP is a fallback, and used when whatever is going to be queried answer is too large for UDP.. That rule should be udp/tcp or if you just want 1 then it should be UDP.

Thanks, changed it to both, now I have a different set of deny's taking place on my FW. Screenshot incoming...

Your rules on eth3 for 5353 are pretty pointless - those are going to be multicast.. And zero reason to let pfsense even see that traffic unless you're going to be using avahi to pass it on to some other network. But the way those rules are written wouldn't be of any good.

Okay, so I don't need them at all with the floating rule I have? I created those based on another thread I found here suggesting them.

your floating rule for 224.0.0.251 should allow your mdns via avahi.. But you could limit that rule down to 5353

Yes, I'm using Avahi on the 3 networks that need to interact for HomeKit/IoT.

edit:
keep in mind the 5353 with avahi would allow discovery, but your going to actually need a rule to allow whatever port(s) your service your going to actually be accessing once discovered.

And what ports would those be?
There are a bunch of threads that say what not to do, but no definitive recipes on how to make HomeKit bombproof.

[tknospdr]

Still getting a lot of blocked traffic for 5353, what am I missing?

I'm also seeing a bunch of NTP requests to random IP addresses. Is it safe to allow port 123 to any dest?

And why do some of my bulbs and switches want to talk to random AWS or CF servers?

[tknospdr]

Alright, some more info...

I found the thread on here talking about ff02::fb and how it's a link local address for IPv6. I created a pass rule for it and it disappeared from my logs.

I still have a bunch of outgoing requests from my smart devices to different servers such as aaplimg.com, akamaitechnologies.com, etc.
I'm guessing they're checking for FW updates and such and not being nefarious??

Also, I figured out the mystery of why 2 of my devices went offline. After combing over the FW rules and logs for a while last night I found out that my 9 year old accidentally unplugged the extension cord those 2 were plugged into.
Ugh.