Everything getting IPv6 addresses all of the sudden.
-
Yes, but they’ve always been on and it hasn’t done this. Also, it has always given itself used 10.0.0.0/24 for its subnet. All the sudden it’s using 192.168.0.0/16. And it’s not like it’s using 192.168.0.1. It’s using bizarre IPs for itself, like 192.168.15.1.
Earlier, when I forced back into the 10.0.0.0/24 range, it left the devices in that range but reset its own IP for 10.0.10.1.
-
Do you still have 10.0.0.0/24 range configured on your Firewalla LAN while seeing devices get an IP from 192.168.0.0/16? If so, sounds like you may have another DHCP server running in the network that's handing out IPs from 192.168.0.0/16. I'd suggest check your network set up and how are things physically connected.
-
So, as an example, I can’t access Firewalla app. It was getting stuck at exchanging keys, reset the network and privacy settings, now it advanced to verifying app access where it gets stuck. But Firewalla is online and handing out IP addresses.
It gave my MacBook 192.168.46.220, my tv another IP in that range, and the DNS server is 10.0.0.1. It’s weird.
All I have is an Xfinity XB8 in bridge mode. So I don’t know where the rogue DHCP server could be.
-
So, I had Xfinity come out and replace the modem. It’s in bridge mode. I also wanted to make sure I had a good phone connection so I started a trial at Visible by Verizon and used that fresh esim in the setup.
I have flashed Firewalla with md5-confirmed software (the md5 hash it displays during flash is different but likely because it’s decompressed). It installs fine.
I then reset network and location settings on my phone.
After that Firewalla will go all the way to verifying app access and then stop completely. I think it may even be serving internet though dangerously so because I can’t setup Active Protect and all that. Nothing more.
If I attempt again, after resetting those settings and attempting a first time, it will get me to exchanging keys and then stop there.
I have reflashed Firewalla five times.
What else can I try?
-
It is serving internet, and still issuing IP addresses in the 192.168.0.0/16 range. Right now my Mac is connected at 192.168.201.220. The MacBook is always assigned a 220 /24 value, whether in the 10.0.0.0/8 or 192.168.0.0/16 ranges.
This is after a flash. I can’t connect the iPhone to control or monitor Firewalla. It’s essentially a rogue device. Serving internet but on what basis and with what settings/protections, who knows?
-
Uhhh… yes, I’m pretty aware that flashing makes it a new unit and you have to re-pair. If you look at everything I just commented, that’s the problem.
I realized the issue I think. And it’s now happened on two units. When I run Angry IP scanner, it shows that Firewallla is getting assigned 198.168.XX.1. All my devices get that range too. When I used Angry Scanner on 10.0.0.0/24, it shows a 10.0.0.1 IP address for Xfinity Broadband Router Server. Firewalla is giving itself 192.168.XX.1 because 10.0.0.1 is taken by Xfinity.
I don’t know whether that means Xfinity router is still running a DHCP server in bridge mode or whether Firewalla is genuinely assigning IPs, but it also means I can’t pair my phone with it to see.
-
Yes, you can open a ticket. But I think I discovered the issue. The Xfinity modem was the rogue DHCP server. The original and the one they replaced it with this morning do not really go into bridge mode. The app will say it’s in bridge mode and it’s not broadcasting any WiFi, but it will be on the network as 10.0.0.1, DHCP server active, even broadcasting its HTTP gateway that can be accessed with an Ethernet cable. It pretends to be in bridge mode but in reality just disabled its WiFi radios.
Firewalla assigns 192.168.XX.1 (sometimes 10.0.10.1) for itself because 10.0.0.1 is taken by Xfinity modem in bridge mode. While in bridge mode, you can run Angry IP Scanner on it and the modem responds “Xfinity Broadband Router Server.”
How do I pursue the ticket?
-
I think the brand new security dongle I just paid $107 and spent two weeks waiting to receive has gone bad.
Found left-over process 165799 (sleep) in control group while starting unit. Ignoring.
Sep 5 10:13:34 localhost systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
Sep 5 10:13:34 localhost systemd[1]: Started Regular background program processing daemon.
Sep 5 10:13:34 localhost root: FIREWALLA:APPLY_PROFILE:DONE
Sep 5 10:13:34 localhost pi: FIREWALLA:MAIN-RUN:DONE
Sep 5 10:13:34 localhost systemd[1]: firewalla.service: Deactivated successfully.
Sep 5 10:13:34 localhost systemd[1]: Finished firewalla.
Sep 5 10:13:34 localhost systemd[1]: firewalla.service: Consumed 35.508s CPU time.
Sep 5 10:13:34 localhost fireboot[169694]: OK
Sep 5 10:13:34 localhost fireboot[169695]: 8
Sep 5 10:13:34 localhost pi: Uptime after firewalla_service_done: 6128.98
Sep 5 10:13:34 localhost systemd[1]: fireboot.service: Deactivated successfully.
Sep 5 10:13:34 localhost systemd[1]: Finished FireBoot.
Sep 5 10:13:34 localhost systemd[1]: fireboot.service: Consumed 2.661s CPU time.
Sep 5 10:13:38 localhost pi: FIREWALLA:UPDATE_ASSETS:START,ASSETSD_PATH=/home/pi/.firewalla/config/assets_extra
Sep 5 10:13:41 localhost pi: FIREWALLA:UPDATE_ASSETS:DONE,ASSETSD_PATH=/home/pi/.firewalla/config/assets_extra
Sep 5 10:13:41 localhost systemd[1]: Stopping LLDP daemon...
Sep 5 10:13:41 localhost systemd[1]: lldpd.service: Deactivated successfully.
Sep 5 10:13:41 localhost systemd[1]: Stopped LLDP daemon.
Sep 5 10:13:41 localhost systemd[1]: Started LLDP daemon.
Sep 5 10:13:41 localhost lldpd[170042]: no libcap support, running monitor as root
Sep 5 10:13:41 localhost lldpd[170045]: protocol LLDP enabled
Sep 5 10:13:41 localhost lldpd[170045]: protocol CDPv1 disabled
Sep 5 10:13:41 localhost lldpd[170045]: protocol CDPv2 disabled
Sep 5 10:13:41 localhost lldpd[170045]: protocol SONMP disabled
Sep 5 10:13:41 localhost lldpd[170045]: protocol EDP disabled
Sep 5 10:13:41 localhost lldpd[170045]: protocol FDP disabled
Sep 5 10:13:41 localhost lldpd[170045]: libevent 2.1.12-stable initialized with epoll method
Sep 5 10:13:42 localhost lldpcli[170044]: system name set to new value Firewalla
Sep 5 10:13:42 localhost lldpcli[170044]: description set to new value Firewalla Gold
Sep 5 10:13:42 localhost lldpcli[170044]: chassis ID set to new value 20:6d:31:01:d6:aa
Sep 5 10:13:42 localhost lldpcli[170044]: lldpd should resume operations
Please sign in to leave a comment.
Comments
16 comments