slackhq/nebula · warning
ErrPeerRejected
ErrPeerRejected
Error message
remote address is not within a network that we handle
What it means
ErrPeerRejected is a sentinel error declared in firewall.go (firewall.go:419) with message "remote address is not within a network that we handle". Firewall.Drop returns it when the remote host's IP resolves to a network of type NetworkTypeVPNPeer: the peer is authenticated but its traffic is not accepted by any firewall rule path yet, so all packets from such peers are dropped. The code comments note this is provisional — VPN-peer networks may one day get their own firewall rule treatment, but currently they are unconditionally rejected.
Source
Thrown at firewall.go:419
if warning := r.sanity(); warning != nil {
l.Warn("firewall rule sanity check",
"table", table,
"rule", i,
"warning", warning,
)
}
err = fw.AddRule(inbound, proto, startPort, endPort, r.Groups, r.Host, r.Cidr, r.LocalCidr, r.CAName, r.CASha)
if err != nil {
return fmt.Errorf("%s rule #%v; `%s`", table, i, err)
}
}
return nil
}
var ErrUnknownNetworkType = errors.New("unknown network type")
var ErrPeerRejected = errors.New("remote address is not within a network that we handle")
var ErrInvalidRemoteIP = errors.New("remote address is not in remote certificate networks")
var ErrInvalidLocalIP = errors.New("local address is not in list of handled local addresses")
var ErrNoMatchingRule = errors.New("no matching rule in firewall table")
// Drop returns an error if the packet should be dropped, explaining why. It
// returns nil if the packet should not be dropped.
func (f *Firewall) Drop(fp firewall.Packet, incoming bool, h *HostInfo, caPool *cert.CAPool, localCache firewall.ConntrackCache) error {
// Make sure remote address matches nebula certificate, and determine how to treat it
if h.networks == nil {
// Simple case: Certificate has one address and no unsafe networks
if h.vpnAddrs[0] != fp.RemoteAddr {
f.metrics(incoming).droppedRemoteAddr.Inc(1)
return ErrInvalidRemoteIP
}
} else {
nwType, ok := h.networks.Lookup(fp.RemoteAddr)
if !ok {
f.metrics(incoming).droppedRemoteAddr.Inc(1)View on GitHub (pinned to dd8f660c0a)
Solutions
- Check which network type the remote address maps to in the firewall's networks table and reclassify it (e.g. via certificate networks/config) so it is not NetworkTypeVPNPeer
- Ensure the remote peer's certificate networks list the specific host CIDR the node expects instead of a broad VPN-peer prefix
- Upgrade or patch nebula if you need VPN-peer traffic support; today the code intentionally drops these packets (see comment at firewall.go:445)
- Verify tunnel setup: if both sides classify each other as VPNPeer, renegotiate certs so addresses fall into handled networks
Example fix
// before: remote cert declares a broad peer network classified as NetworkTypeVPNPeer // cert networks: ["10.100.0.0/16" (vpn-peer)] // after: declare the specific host range the local node handles // cert networks: ["10.100.1.0/24"] // falls into a handled network type, Drop proceeds past the NetworkTypeVPNPeer case
Defensive patterns
Strategy: validation
Validate before calling
// before relying on traffic, confirm how the firewall classifies the remote address
if fw.GetNetworkType(remoteAddr) == NetworkTypeVPNPeer {
// address will be rejected by Drop (firewall.go:445); reconfigure cert networks first
} Try / catch
// nebula returns error values, not panics
if err := fw.Drop(pkt, incoming, host, caPool, cache); err != nil {
if errors.Is(err, firewall.ErrPeerRejected) {
// peer classified as NetworkTypeVPNPeer: fix cert networks or wait for peer-rule support
}
} Prevention
- Keep peer certificates listing only networks the receiving node can classify as regular handled networks
- Avoid issuing certs whose networks overlap the designated VPN-peer range unless peer firewall rules are supported in your build
- Review the network-type classification of your CIDR plan before rollout
When it happens
Trigger: Calling Firewall.Drop on a packet whose HostInfo remote address falls into a prefix classified as NetworkTypeVPNPeer in the firewall's network table (firewall.go:445), i.e. a peer whose cert networks map to the VPN-peer network type rather than a regular host/unsafe network.
Common situations: Deployments where peers are provisioned with certificates containing network/CIDR entries that the local node classifies as NetworkTypeVPNPeer; mixing node types or configurations where one Nebula node treats another's address space as 'vpn peer' range; staged rollouts where the peer-network firewall feature is not yet implemented.
Related errors
AI-assisted analysis of slackhq/nebula@dd8f660c0a (2026-09-03).
Data as JSON: /api/errors/3f8725c2c29e81c7.
Report an issue: GitHub.