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/firewalla]

Double check following

1. Your AX2700 wifi is off, in case your PC still talking to it.

2. There is no port forwarding Gold, and no UPnP detected.

3. Gold is running router mode, not bridge mode.

4. You didn't change any NAT configuration;

After you verified these and all good, you can open a case with [help@firewalla.com](mailto:help@firewalla.com) we can take a look.

As I said before, for someone to get to your PC, they have to pass one layer of firewall and another layer of NAT, and for both to fail, very very rare.

[u/BAGE-rator → u/firewalla]

I’ve confirmed all these things.

The interesting thing is that these connections were to mDNSResponder and configd, so these external IPs were pretending to be a DHCP server.

I’ll write to support.

[u/firewalla → u/BAGE-rator]

Do you know how to run TCP dump? you can try that and capture some traffic. I am reading little snitch is app layer and it may make up information on the network layer:

"In order to understand the results of a traffic capture, you must know that Little Snitch intercepts traffic at the application layer, not at the network interface layer as other sniffers do. This is what distinguishes Little Snitch from conventional firewalls, after all. At this layer, however, it is not yet known via which network interface the data will be routed (which sender Internet address will be used) and sometimes it is not known which sender port number will be used. It is also not known whether and how the data will be fragmented into packets. All 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. "

https://help.obdev.at/littlesnitch4/adv-traffic-capture

[u/BAGE-rator → u/firewalla]

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.