What a Martian Packet Is
A martian packet is an IP packet whose source address is impossible given the network interface through which it arrived. The term comes from the idea that the packet claims to originate from a place that simply cannot exist on that particular wire — as absurd as receiving a letter from an address on another planet.
More formally: when a router receives a packet on a specific interface, it checks whether the source IP address of that packet makes routing sense for that interface. If its routing table says that source address should only ever appear on a different interface — or if the source address belongs to a range that is by definition unroutable on the public internet — the packet is flagged as a martian and discarded.
Understanding martian packets matters because they are among the clearest signals of IP spoofing, routing misconfiguration, or both. A network that logs and monitors for martians gets advance warning of attack traffic and misconfigured equipment before either causes an incident.
How Routers Detect Martian Packets
Detection relies on two mechanisms that work at the routing layer:
Unicast Reverse Path Forwarding (uRPF)
uRPF is the primary mechanism for martian detection on modern routers. When a packet arrives on an interface, the router performs a reverse lookup: it checks its routing table to see where it would send traffic to the packet's source address. If the routing table says traffic to that source address would go out a different interface than the one the packet arrived on, the packet fails the RPF check and is dropped.
uRPF has two modes:
- Strict mode: The packet must arrive on the interface that the routing table would use to reach the source address. One expected path, strict enforcement. Best for single-homed environments.
- Loose mode: The source address just needs to exist somewhere in the routing table — it does not have to match the specific incoming interface. Less protective but compatible with asymmetric routing where return path differs from forward path.
Linux implements uRPF behavior through the rp_filter kernel parameter. Setting net.ipv4.conf.all.rp_filter=1 enables strict mode; 2 enables loose mode.
Bogon and Martian Address Filtering
Beyond uRPF, routers explicitly filter packets with source addresses from ranges that should never appear as sources on the public internet:
- Private address ranges:
10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 - Loopback:
127.0.0.0/8 - Link-local:
169.254.0.0/16 - Multicast:
224.0.0.0/4 - Reserved/documentation ranges:
192.0.2.0/24,198.51.100.0/24,203.0.113.0/24 - Broadcast:
255.255.255.255/32 - This address:
0.0.0.0/8
Packets from these ranges arriving on an internet-facing interface are definitively martian — those addresses have no routing on the public internet, so any packet claiming to come from them is either spoofed or misrouted.
Why Martian Packets Exist
Martian packets are produced by three different conditions, each with different implications:
IP Address Spoofing
Spoofing is the primary concern. An attacker crafts packets with a false source IP address — either to impersonate a trusted host (making their traffic appear to come from inside the victim's network) or to obscure their real address during an attack. DDoS reflection attacks commonly use spoofed source addresses: the attacker sends requests with the victim's IP as the source, causing large responses to be sent to the victim from many amplification servers.
BCP38 (RFC 2827) defines the industry-standard response: ISPs should apply ingress filtering at network edges, dropping any packet from a customer whose source address is not within the address space assigned to that customer. If universally implemented, spoofing that uses addresses from other networks would be impossible. In practice, BCP38 adoption is incomplete, and spoofed packets continue to traverse parts of the internet.
Routing Misconfiguration
In complex enterprise networks, routing loops or misconfigured static routes can cause packets to arrive on the wrong interface. A route pointing to the wrong next-hop will cause packets from the attached subnet to appear on an unexpected interface, triggering uRPF drops and generating martian log entries. These misconfiguration martians are valuable diagnostic signals — they point directly to the routing error.
Testing and Research
Network engineers use crafted martian packets to test the effectiveness of filtering rules and firewall policies. Tools like Scapy allow arbitrary source addresses to be set in test packets. If the test packet is not dropped at the expected filter point, the configuration has a gap. This use of martians is deliberate and controlled.
Martian Packets vs. Bogons
| Category | Definition | Detection Method | Example |
|---|---|---|---|
| Martian Packet | Source IP impossible for the arriving interface (routing context violation) | uRPF, interface-aware filtering | Private IP arriving on internet-facing interface |
| Bogon Address | IP address from ranges not allocated for public internet use | Static bogon filter lists | 192.168.0.0/16 as source on WAN link |
| Unallocated Space | IP ranges not yet assigned by RIRs | Regular WHOIS/RIR prefix list updates | Formerly unallocated /8 blocks |
| Spoofed Packet | Any packet with a falsified source address regardless of range | uRPF, rate anomaly detection | Any source IP that does not route back to the interface |
Enabling Martian Logging on Linux
Linux kernels log martian packets when the log_martians sysctl parameter is set. Enable it with:
sysctl -w net.ipv4.conf.all.log_martians=1
Make it persistent by adding net.ipv4.conf.all.log_martians=1 to /etc/sysctl.conf. Martian packet events then appear in kernel logs (dmesg or /var/log/kern.log) with entries like:
IPv4: martian source 192.168.1.100 from 10.0.0.5, on dev eth0
This log entry identifies the receiving interface, the claimed source address, and the actual interface on which the packet arrived — all the information needed to trace the source of the spoofed or misrouted traffic.
Real-World Use Cases
DDoS amplification detection: Reflection and amplification attacks (DNS, NTP, SSDP) depend on spoofed source addresses pointing to the victim. Ingress filtering that drops packets with private or martian source addresses at the ISP edge reduces the attack traffic reaching the victim. Networks that implement BCP38 filtering effectively eliminate amplification attacks originating from their customers.
Security incident investigation: During a security incident, unexpected martian log entries on an internal router can reveal a compromised host using spoofed addresses to probe internal targets, an attacker who has bypassed perimeter controls, or a misconfigured network device generating routing loops.
Network commissioning validation: After configuring a new network segment, sending test packets with martian source addresses and verifying they are dropped at the intended filter points confirms that antispoofing controls are working correctly before the segment goes into production.
Common Misconceptions
Martian filtering is automatic on all routers
It is not. uRPF and explicit bogon filtering must be explicitly configured. Consumer routers often lack uRPF entirely. Enterprise routers have it available but it must be enabled and configured correctly. ISP edge routers should implement BCP38 filtering but many do not. The security benefit of martian filtering depends entirely on whether it has been deliberately deployed.
Martian packets are always the result of an attack
Not always. Routing misconfigurations, asymmetric routing configurations where uRPF is too strict, and testing traffic can all produce martian events. A sudden spike in martian log entries is worth investigating, but each entry is not automatically an attack. Correlate martian events with other signals — traffic volume, destination ports, timing patterns — before drawing conclusions.
Blocking martians breaks legitimate traffic
For public-facing internet interfaces, blocking martians does not break any legitimate traffic. Source addresses from private ranges, loopback, and documentation ranges have no business appearing on a WAN interface. Legitimate traffic always uses real routable addresses. The only scenario where uRPF causes false drops is asymmetric routing — where traffic arrives on a different interface than the routing table's best path to the source. In that case, loose mode uRPF is the correct setting.
Martian filtering alone stops IP spoofing
It significantly reduces spoofing using obviously invalid addresses but does not stop spoofing that uses valid routable addresses from other networks. An attacker can spoof a source address from another organization's IP block, and that will not be caught by simple martian filtering. Full BCP38 enforcement at ISP edges — which verifies that source addresses match customer allocations — is needed to stop that class of spoofing.
Pro Tips
- Enable log_martians on every production Linux router. The logs cost almost nothing but provide early warning of spoofing, routing misconfiguration, and unauthorized network access. Configure log rotation to retain at least 30 days of martian logs for forensic purposes.
- Use strict uRPF on single-homed interfaces and loose mode on multi-homed ones. Strict uRPF on interfaces with asymmetric routing will drop legitimate traffic. Audit your routing architecture before enabling strict mode. Most internet-facing interfaces on ISP-connected equipment benefit from at least loose mode uRPF.
- Automate bogon list updates. Unallocated IP address space changes as RIRs distribute address blocks to registrants. If your firewall has a static bogon list, it may become outdated. Use regularly updated block lists from trusted sources or implement automated prefix list updates via your router's configuration management.
- Alert on sudden spikes in martian events, not individual packets. A few martian packets per hour may be background noise. Hundreds or thousands per minute from a specific source or targeting a specific destination is a signal worth immediate investigation.
- Implement BCP38 filtering if you operate network infrastructure. If you run an ISP, hosting provider, or enterprise with customer-facing connections, implement source address validation to prevent your network from being used as a spoofing origin. This protects the broader internet as much as your own infrastructure.
Check whether your IP passes basic antispoofing validation tests.