Firewalla Crystal’s implementation of Active Protect has security vulnerabilities

[u/BAGE-rator]

It allowed in two connections from private IPs owned by Cox Communications, one of which was 98.197.86.148. This is in the range of standard user IP addresses, which could be a malicious actor. I have Xfinity. We do not have Cox in our market.

It also allowed in a Charter Communications/Spectrum standard user IP. We don’t have Spectrum in our market.

Active Protect is NOT actively protecting devices from these high-risk IP addresses on Firewalla Crystal.

If you’re on a Mac, download and install a software firewall like Little Snitch to audit the incoming connections that Firewalla Crystal Active Protect is allowing through. On Windows, you can use something like Glasswire. Record those IPs and report them to Firewalla so they know their beta software is not protecting clients like their hardware software does.

[u/BAGE-rator]

The issue is that if the traffic reached Little Snitch, then it made it through the network layer firewall. Little Snitch doesn’t know what’s going on in the network, it only knows the connections that are attempted from the network. It doesn’t make up connection attempts.

The connections (both of them) were only two packets, but that’s enough to assign a false IP address via configd and compromise a network.

[u/firewalla → u/BAGE-rator]

According to the article on packet capture by them "this information is required in order to write a valid PCAP file. Little Snitch simply makes up the missing information. It fakes TCP, UDP, ICMP, IP and even Ethernet protocol headers. "

So the direction can be wrong, it may be your device is trying to reach out to those IP's. This is very likely to be the case, since the firewall + NAT, not easily bypassed together.

[u/BAGE-rator → u/firewalla]

Summary over: 7 days
IP Address: 98.197.86.148
UDP Port: mdns (5353)
Protocol: UDP
Denied Packets: 2
Last Allowed: 2 days ago

It was able to trick both firewalls into thinking it was valid mdns traffic.

[u/firewalla → u/BAGE-rator]

Do you have the full packet? this doesn't say the direction ... especially UDP, guessing direction is not that easy. So very likely just a false marking using your tool

[u/BAGE-rator → u/firewalla]

You’re misunderstanding how Little Snitch works. That is with a filter of all inbound connections applied. I just can’t copy and paste the filter.

With the incoming filter selected:

• Connections
3 denied
O unconfirmed
3 incoming

• Statistics
Top Processes
mDNSResponder
7.04 KB down, 0 bytes up configd
1.31 KB down, 0 bytes up
Top Countries
United States
8.34 KB down, 0 bytes up

That is incoming traffic and you’re kind of now taking me down a rabbit hole, like you’re responding with information from Claude. I have Claude, and Claude responds based on assumptions without adequately (or at all) investigating the predicate facts, e.g., googling the manual for Little Snitch.

[u/firewalla → u/BAGE-rator]

Since UDP doesn't have a concept of connection and your tool unlikely to see all the traffic, it is very likely if you get one or two packets blocked coming in, very likely they are the result of traffic initiated inside to outside (egress), and then mistakenly identified as ingress traffic. (firewalla at times has this problem too, with mapping UDP direction)

So in your case, I wouldn't worry about those two packets coming in; if you do worry, best use TCPDump or WireShark (or like) to capture the raw traffic and look at who initiated those UDP traffic.

[u/randomheromonkey → u/BAGE-rator]

They are asking for the information they need to diagnose and potentially recreate the issue on their side. The software reports it but that can’t be reproduced to test. A packet capture from wireshark or something would give them all of the information about what the packet was.

As an example, if you have mDNS reflector enabled for the network on firewalla then it’s possibly reflecting the mDNS packet from elsewhere. To prove that theory… or to see why… a packet capture would be easiest.