Bogons and martians: the addresses that should never reach you
Somewhere in your firewall logs is a packet whose source address cannot exist: private space arriving from the open internet, or a range nobody has ever been allocated. Operators call the addresses bogons, and the log entries martians, and they are one of the few cases in this business where an address tells you something with certainty. Nothing legitimate sends them. Here is what they are, where they come from, and how to filter them without breaking things later.
What a bogon is
A bogon is an address that should not appear as a source on the public internet, for one of two reasons. Either it is reserved by standard, the private ranges, loopback, link-local, documentation space, the CGNAT shared range, everything in the special-use table, or it has never been allocated by the registries to anyone at all. Both kinds have the same property: no legitimate host on the open internet holds such an address, so a packet claiming one as its source is lying about where it came from. The word martian is the older, narrower cousin: a packet whose source or destination is impossible on the interface it arrived at, named for coming, as far as the router can tell, from Mars.
Why you still see them
Three mundane sources produce almost all of them. Spoofing: attackers forge source addresses, for denial-of-service reflection especially, and reserved space is a lazy choice of forgery. Leaks: a misconfigured network lets its private or CGNAT addressing escape through a router that should have translated or dropped it, which is why a 10.x source at your edge usually points at a neighbour's plumbing rather than an attack. And configuration ghosts: test ranges and documentation addresses copy-pasted into real configs eventually emit real packets.
One thing has changed over the years: the unallocated kind of bogon has nearly vanished from IPv4. When registries still held large free pools, whole /8s were bogons until the day they were issued; with the free pools gone, almost every routable IPv4 address is allocated to somebody, and the bogon lists that matter day to day are effectively the reserved ranges. IPv6, mostly unallocated by volume, is a different story, and its bogon space is vast.
What a martian in your logs means
Read them as a signal about paths, not people. A martian carries no attribution: the address is forged or leaked by definition, so there is nobody to look up and no abuse contact to mail, which is exactly the opposite of an ordinary investigation. What a martian does tell you is that a path exists which should not: an upstream not filtering spoofed sources, a VPN or tunnel dumping internal addressing onto the wire, or your own gear routing ranges it should drop. A trickle is background radiation of the internet; a surge, especially alongside traffic spikes, is worth treating as the early edge of a spoofed attack.
Filtering, and the trap inside it
The defence is old and standard: drop packets with impossible sources at your edge, and never announce or accept routes for reserved space. The reserved ranges are stable and safe to filter, but not permanently: the list still changes, with IANA entries added as recently as 2025, so re-pull it rather than setting it once. Today it is a short table.
The trap is the other kind of list. Filters built on unallocated space age badly, because allocation is a moving fact: ranges that were bogons for years get issued, and stale filters then silently block legitimate new networks. The address market has made this worse, since long-dormant space now returns to life through transfers, and a buyer of such space can inherit years of other people's stale bogon filters along with the block, one more way a range arrives pre-broken. The rule: static filters for reserved space, automatically updated feeds or no filter at all for allocation state, and if you hold newly revived space, checking who still filters it belongs on your list.
Checking a suspect address
When an odd source shows up, the first question is which kind of odd it is, and a lookup answers it in one step: reserved space comes back labelled with its RFC and the plain statement that it has no holder and no routing history, while a real allocated address comes back with its network, its history and its reputation. The first kind ends the attribution question immediately, and honestly, which is its own kind of useful answer. The second kind starts a real investigation. Knowing which door you are standing in front of, before you push, is what the check is for.
Paste any suspicious source address into the front page. Reserved space explains itself instantly, with the RFC that reserved it; everything else returns the network behind it and its dated history, with every fact sourced.