You know what's funny? We spend all this time talking about firewalls on servers and laptops, and most people don't even think about the computer in their pocket. Daniel's been chewing on this one. He points out that we associate firewalls with the network level or at most with desktops, and that leads to this blind spot where nobody asks whether a smartphone even has a firewall, or whether it needs one. He says a lot of people will fire up a VPN the second they connect to airport Wi-Fi, but they never think about what ports their phone might have wide open. So he's asking three things. One, what's the actual default posture on an Android device — what's listening, what's exposed? Two, how strong is the case for an always-on firewall, or maybe something smarter that only kicks in on untrusted networks? And three, the one I hadn't really thought about: when you're on cellular data, what's the topology? Are you sitting on a giant LAN with every other subscriber, and is lateral movement across that network a real thing, or are clients isolated? Let's start with what your phone is actually exposing right now.
The short answer is more than most people think, and less than a desktop — but the gap is in the defaults, not the capability. An Android device is a general-purpose computer running a Linux kernel. It has a full network stack. It has services. It has apps that can open sockets. And here's the thing that trips people up: there is no user-facing firewall. On Windows, you've got Defender Firewall sitting there, on by default, blocking inbound connections unless you explicitly allow them. On a Mac, same deal. Android has netfilter — the same kernel-level packet filtering framework that iptables uses — but Google doesn't expose any of it to the user. There's no settings menu, no toggle, nothing.
So the machinery is there, but the steering wheel is in the trunk.
The kernel can filter packets. It does filter packets, actually — there are default iptables rules that ship with Android. But they're minimal. They block some broadcast traffic, they enforce the sandboxing between apps to some degree, but they don't act as a traditional host-based firewall. Any app with the INTERNET permission — which is something like ninety-five percent of apps — can open a listening socket. It can bind to a port. And the user never gets asked about it.
What kind of ports are we talking about? Give me something concrete.
ADB is the one that comes up most in security research. Android Debug Bridge — it's the developer tool that lets you run shell commands from a computer. On stock Android, you can enable ADB over Wi-Fi. When you do, it listens on port fifty-five fifty-five. If you leave that on in a coffee shop, anyone on the same network can try to connect. On custom ROMs, there have been builds that shipped with ADB over Wi-Fi enabled by default — which is a disaster, and it's been caught and fixed, but it keeps happening. Beyond ADB, you've got media servers, DLNA services on TV boxes running Android, sometimes SSH servers if someone's installed Termux and set that up. The point isn't that every phone is a sieve — it's that the OS doesn't stop you from becoming one.
So the default posture is: the kernel can filter, but it mostly doesn't, and apps can open ports without telling you. That feels like a design choice, not an oversight.
It is a design choice. The Android security model is built around app sandboxing, not network perimeter defense. The assumption is that the threat comes from malicious apps, not from network attackers. And for a phone in someone's pocket on cellular, that's mostly true — we'll get to why. But it falls apart on Wi-Fi, and it really falls apart when you look at Android devices that aren't phones. Smart displays, TV boxes, Android-based IoT gadgets — those sit on a LAN their whole life, often with no updates, and the same default posture applies.
Daniel mentioned this exact gap. People use a VPN on untrusted Wi-Fi out of habit, and they think that's them being security-conscious. But a VPN encrypts outbound traffic. It doesn't close your listening ports.
Right. The VPN creates an encrypted tunnel for the traffic your phone initiates. If an app has bound to port eight thousand and is listening for incoming connections, the VPN doesn't touch that. The port is still open on the local network interface. Anyone on the same Wi-Fi network can reach it. The VPN is doing nothing for inbound connections — it's not a firewall, it's a encrypted pipe for outbound data. That's the gap Daniel's pointing at, and he's exactly right.
Okay, so that's Wi-Fi. Let's get to the part that surprised me. Cellular. Daniel says he's always assumed that when you're on 4G or 5G, you're effectively on a giant LAN with every other subscriber on that carrier. Is that how it works?
It's a reasonable assumption, and it's mostly wrong — but not completely wrong, and the exceptions are interesting. Here's the topology. When your phone connects to a 4G or 5G network, it's assigned an IP address. In the vast majority of cases, that IP address is a private one — a ten dot x dot x dot x address, or a hundred dot x in some carrier configurations. You're behind carrier-grade NAT. The carrier runs massive firewalls and NAT gateways between the radio access network and the public internet. Inbound connections from the internet are blocked by default. You cannot reach a phone on cellular from the public internet just by its IP address — the carrier simply won't route it.
So the carrier is running the firewall for me. That's... actually kind of nice.
It is, and it's the main reason why the "phones don't need firewalls" argument has held up for so long. The carrier inherited the walled-garden model from the old telecom world. In the circuit-switched days, the network was the secure perimeter. When data services came along — GPRS, then 3G, then LTE — carriers kept that assumption. They NAT everything, they filter everything, they don't let subscribers talk to each other directly. For most users, on most carriers, most of the time, your phone is not reachable from the internet and not reachable from other subscribers.
Most of the time.
It is. Let's talk about the exceptions. First, device-to-device communication. Some carriers do allow direct subscriber-to-subscriber IP communication within their network — it's used for things like VoLTE, video calling, sometimes RCS messaging. The traffic doesn't go out to the internet and back; it routes internally. That means if there's a vulnerability in how the carrier isolates those internal routes, one subscriber could potentially reach another. Second, IPv6 changes the picture. 4G and 5G networks increasingly assign IPv6 addresses, and those are often globally routable — they're public IPs. The carrier still firewalls inbound connections from the internet, but the address itself is not hidden behind NAT the way an IPv4 address is. That's a shift in the threat model that hasn't fully played out yet.
So on IPv6, my phone has a public address. The carrier says they're blocking inbound — but if that block fails, or if they don't configure it right, I'm suddenly reachable.
In theory, yes. In practice, the major carriers are competent at this — they've been running IP networks for decades. But the attack surface is larger with IPv6 because there's no NAT hiding you by default. You're relying entirely on the carrier's firewall rules being correct and consistently applied. And carriers make mistakes. There have been academic papers — researchers at TU Berlin and others — that found misconfigurations in carrier IPv6 deployments where subscriber devices were reachable from the internet when they shouldn't have been.
What about lateral movement between subscribers? That's the thing Daniel's really asking. Can some attacker on the same cellular network reach my phone directly?
The short answer is: it's hard, but not impossible. The carrier's infrastructure is designed to isolate subscribers from each other. The eNodeB — the cell tower — doesn't route traffic between devices attached to it. Everything goes back to the core network, through the carrier's routing and firewall infrastructure. But there are known vulnerabilities in the GTP protocol — that's GPRS Tunneling Protocol, which is what carries user data between the radio network and the core. Researchers have demonstrated GTP-based attacks where an attacker can spoof packets, intercept traffic, or in some cases reach other subscribers. These are not trivial attacks — you need to be on the carrier's backbone or have compromised a network element. It's not something a guy with a laptop at a bus stop can do. But it's been demonstrated. The risk is real, just very low compared to being on a shared Wi-Fi network.
So cellular is not a giant LAN. It's more like a bunch of private hallways that all feed into a central guarded lobby. Normally you can't walk into someone else's hallway. But the guards have occasionally left a door unlocked.
The guards being the GTP implementation — which is ancient, by the way. GTP was designed in the late nineties for GPRS, and it's been extended and patched ever since. It wasn't built with modern threat models in mind. There have been multiple GSM Association security advisories about GTP vulnerabilities over the years. The industry knows about this. They're working on it. But replacing core network protocols is like replacing the engines on a plane while it's flying — it happens slowly.
So where does that leave us on the firewall question? If cellular is mostly isolated, does the case for a mobile firewall collapse?
No, because the threat model isn't uniform. On cellular, the risk of inbound attacks is low. On Wi-Fi, it's much higher — you're on a shared LAN with strangers. On public Wi-Fi, it's higher still. On a compromised home router, which is more common than people think, it's very real. A smart firewall wouldn't be always-on with the same rules everywhere — it would be network-aware. Tight rules on untrusted networks, relaxed on your home network, relaxed on cellular. That matches the actual risk.
And what does that look like in practice? What tools exist?
There are basically two approaches on Android, and they illustrate the tradeoffs perfectly. One is AFWall plus — it's an iptables frontend that requires root access. It gives you full control: per-app rules, per-interface rules, custom iptables chains. You can block an app from using Wi-Fi but allow cellular, block all inbound on public Wi-Fi, whatever you want. It's powerful, it's granular, and it requires you to root your phone — which breaks SafetyNet, breaks banking apps, breaks Google Pay. Not a realistic option for most people.
And the other approach?
NetGuard. It doesn't require root. It works by creating a local VPN interface on the device and routing all traffic through it, where it can apply filtering rules. Per-app blocking, per-network rules, logging. It's clever. But the tradeoff is that all your traffic goes through this local VPN, which means the app itself can see everything — it has to, to filter it. And you can't run a real VPN at the same time, because Android only allows one VPN connection. So you're choosing between encrypted tunnel to a remote server and local firewall filtering. That's a bad trade to have to make.
So your options are root your phone and break half its features, or give a third-party app access to all your traffic and give up your actual VPN. That's... not great.
It's a genuine gap in Android's security model. Google has all the pieces. The kernel has netfilter. Android has the eBPF traffic monitor — it's a framework they built for network observability that can see every packet flowing through the device. It's used for things like data usage tracking and battery optimization. They have the visibility. They just haven't built the user-facing controls. There's no firewall settings page. There's no per-app network permission beyond the binary internet on-off toggle. The infrastructure is there, the interface isn't.
And you mentioned Android sixteen is adding some anti-stingray settings?
Yeah, Android sixteen — which is in development now — is adding settings to detect and block stingrays, those fake cell towers that law enforcement uses. Your phone will be able to alert you if it's connected to a suspicious cell site, and there are options to require encryption and disable downgrades to older, less secure protocols. It's a real step forward for network-level security awareness. But it's not a firewall. It's about the cellular radio layer, not IP filtering. It's Google acknowledging that the network isn't always trustworthy — which is exactly the premise of Daniel's question — but they're addressing it at the radio level, not the IP level.
Right. A stingray is someone impersonating the tower. That's a different attack than someone on the same Wi-Fi scanning for open ports.
Completely different. And it's interesting that Google is willing to add anti-stingray controls but not a basic firewall. I think part of it is philosophy — Android's security team has always prioritized sandboxing and permissions over network controls. Part of it is carrier relationships — carriers don't want users messing with network settings and then calling support when things break. And part of it is the app ecosystem — if you give users per-app firewall controls, suddenly every app that relies on background connections for ads or analytics breaks, and the developers complain.
So the case for a firewall is strongest for power users, for Android IoT devices, and for people who sideload apps. For the average person who only installs from the Play Store and mostly uses cellular data, the default posture is... acceptable?
Acceptable on cellular. Risky on Wi-Fi. And most people spend a lot of time on Wi-Fi — at home, at work, at coffee shops. The home network is the one people trust the most, and it's also where a lot of vulnerable IoT devices live. If your phone has an open port and your smart fridge is compromised, the fridge can reach the phone. That's not theoretical — IoT botnets scan local networks all the time.
So Daniel's instinct is right. The VPN habit is good but incomplete. And the firewall question isn't just for servers anymore.
The phone is a server. That's the reframe. It runs services, it listens on ports, it has a persistent network connection, it has a public or semi-public IP address. The fact that it fits in your pocket doesn't change what it is at the network level. We've just been trained not to think of it that way.
And the cellular LAN assumption — it's not a LAN, but it's not a fortress either.
The thing about carrier NAT is that it's a happy accident of IPv4 address exhaustion. Carriers didn't deploy NAT to protect subscribers — they deployed it because they ran out of public IPv4 addresses. The security benefit was a side effect. As we move to IPv6, that side effect goes away. We're going to need to be more intentional about mobile device security, and right now we're not.
You know what this reminds me of? The early days of broadband. When everyone moved from dial-up to always-on cable and DSL, suddenly every home computer had a public IP and no firewall, and the worm outbreaks were catastrophic — Blaster, Sasser, all of that. It took years for host-based firewalls to become standard on Windows. We're kind of at the same inflection point with mobile and IPv6, but in slow motion.
That's exactly the parallel. And the difference is that phones have way more sensors, way more personal data, and way more persistent connectivity than those Windows XP machines ever did. The stakes are higher.
So what should someone actually do? Daniel's asking a practical question underneath the technical one.
If you're on stock Android, not rooted, and you want to close the gap: first, disable anything you don't need. ADB over Wi-Fi — turn it off. Wi-Fi Direct, Bluetooth tethering, any service that listens — off unless you're actively using it. Second, use a VPN on untrusted Wi-Fi — Daniel's already doing that, and it's still good practice for outbound privacy. Third, consider NetGuard if you're willing to trade the VPN slot for firewall control, especially if you sideload apps or use a lot of sketchy free software. Fourth, keep the OS updated — a lot of port-exposure vulnerabilities get patched in monthly security updates. And fifth, if you're running Android on something that's not a phone — a TV box, a smart display, a tablet that lives on your network — treat it like the IoT device it is. Put it on a separate VLAN if you can. Don't assume it's locked down just because it's Android.
And if you are willing to root?
AFWall plus is the gold standard. Full iptables control. You can build rules that are network-aware — tight on public Wi-Fi, relaxed at home, permissive on cellular. You can block individual apps from ever touching the network. You can log everything. It's what a built-in Android firewall should be. But again, rooting is its own can of worms. You're trading one set of security assumptions for another.
The fact that those are the two options — break your phone's security model or give a third-party VPN app all your traffic — is kind of an indictment of the platform.
It is. And Google knows it. The eBPF traffic monitor shows they're thinking about network observability. I wouldn't be surprised if a future Android version adds some kind of network permission model that's more granular than the current on-off toggle. But a full firewall? I think they're reluctant to go there because of the support burden. The moment you give users firewall controls, you're on the hook when their apps break.
Which is the same reason Windows took so long to turn on their firewall by default. Microsoft knew it would break things. They did it anyway after Blaster. Sometimes it takes a disaster.
The mobile Blaster hasn't happened yet. And it might not — the threat models are different. But the conditions are accumulating. More devices, more always-on connectivity, more IPv6, more services listening. At some point the probability crosses a threshold and someone gets burned badly enough that the industry moves.
Hilbert, you've been quiet — you look like you've got a story about this.
Hilbert: Late nineties. I was doing network admin for a small ISP in Connecticut. We did dial-up, and we had a CDPD service — that's Cellular Digital Packet Data, early mobile data before GPRS. Nineteen point two kilobits per second. Felt fast at the time.
CDPD. I haven't heard that acronym in years.
Hilbert: We had a rack of modems and a T1 line. I configured firewalls for every customer who wanted a business connection. Never once configured one for a phone. Phones didn't have IP stacks. They had WAP browsers. The network was the secure perimeter. The carriers sold it that way. Private network, they said. No internet exposure. And they were mostly right, because there was nothing to expose.
The assumption that cellular is secure by default — that's a fossil from the WAP era?
Hilbert: It's a fossil from before that. It's from the circuit-switched voice world. A phone call was a dedicated circuit between two endpoints. Nobody could jump onto your circuit. When data came along, the industry just kept thinking the same way. Walled garden. The network protects you. The device is dumb. Nobody updated the assumption when the devices got smart.
When did you first realize that assumption was breaking?
Hilbert: Two thousand one, maybe two thousand two. We had a customer — construction company, their foreman had a Nokia with one of those early HTML browsers. He called because his data usage was through the roof. I pulled the firewall logs from our CDPD gateway. His phone's IP — it was a private ten dot address behind our NAT — was getting scanned. Hundreds of connection attempts. SSH, telnet, NetBIOS, the usual script-kiddie stuff. Some botnet had found a range of IPs that included our gateway and was just spraying.
But he was behind NAT. How were they reaching him?
Hilbert: They weren't. The scans were hitting our gateway, not his phone directly. But the gateway was passing some of that traffic through — misconfigured port forwarding on our end. Nothing reached his phone, but it was close. And the point is, his phone was visible enough to be in the logs. It wasn't invisible. It was just behind a single point of failure — me, and my iptables rules, at two in the morning.
The carrier-level protection is only as good as the carrier's configuration.
Hilbert: Always has been. I was good at my job, but I wasn't perfect. Nobody is. The big carriers have whole teams, but they also have decades of accumulated config, old kit that nobody wants to touch, protocols that were designed when the biggest threat was someone stealing long-distance minutes. GTP is from that era. We ran a GTP tunnel to the upstream carrier for our CDPD traffic. I read the spec once. The authentication was... not what you'd design today.
What happened to the construction foreman?
Hilbert: We fixed the port forwarding, throttled his data, he went back to checking email at nineteen point two k. But I kept the logs. Still have them somewhere. A Nokia getting scanned by a botnet in two thousand one. That's when I stopped believing the network was secure.
That was twenty-five years ago. The devices have gotten a thousand times more capable, and the assumptions haven't changed.
Hilbert: The assumptions are the same. The devices are computers. The carriers still talk about the network as a secure perimeter. I've got four Android TV boxes in my apartment. Every one of them has ADB enabled because I use them for development. If I put them on the wrong VLAN, they'd be wide open. I don't, because I know what I'm doing. Most people don't.
Four Android TV boxes. Why four?
Hilbert: Different chipsets. I was comparing HDR implementations. The Amlogic one has better deinterlacing. The Rockchip one runs cooler. The other two are spares.
Of course they are.
Hilbert: The point is, every one of those boxes is a general-purpose Linux computer running Android. They all have network stacks. They all have services listening. None of them have a firewall. If I didn't segment my network, they'd be a buffet. And they're sold at Best Buy next to the toasters. Nobody tells the buyer any of this.
You're running your own network segmentation at home to compensate for the fact that Android doesn't ship with a firewall.
Hilbert: VLANs, separate SSIDs, the whole thing. It's not complicated. A fifty-dollar managed switch and an afternoon. But I shouldn't have to. The OS should do it.
That's the whole episode right there. The OS should do it.
The OS has the machinery. It just doesn't have the controls. And until it does, we're all relying on carrier NAT that was an accident of IPv4 exhaustion, firewall rules configured by someone who might be having a bad day, and the hope that nobody on the coffee shop Wi-Fi is running a port scanner.
The phone is a computer. It's treated like a dumb terminal. That's the problem. And the gap between those two things is where the risk lives.
Thanks to Hilbert Flumingtop for producing, and for the four Android TV boxes we didn't know about.
That's going to stick with me. Four boxes.
This has been My Weird Prompts. If you want to yell at us about firewall rules, the website is my weird prompts dot com. We'll be back soon.
