Skip to main content
Docs
English日本語
Login

IP Rules

IP rules are evaluated by most-specific-match (longest match), not by their order in the list. When multiple rules match the same packet, the most specific r…

Traffic Filtering IP rules match outbound traffic by destination IPv4 CIDR, protocol, and port. For an overview of Traffic Filtering and how rules are evaluated, see Traffic Filtering. To configure rules in the User Console or via the Soracom API, see Configuration.

IP Rule Priority

IP rules are evaluated by most-specific-match (longest match), not by their order in the list. When multiple rules match the same packet, the most specific rule takes precedence. This lets you express a broad baseline rule together with narrower overrides without worrying about ordering.

Priority is determined independently for each type:

TypePriority
CIDR rangeNarrower range takes precedence over broader range.
ProtocolSpecified protocol takes precedence over unspecified (ANY / 255).
PortSpecified port takes precedence over unspecified.
Port rangeNarrower range takes precedence over broader range.

The following examples show the most common patterns. The CSV format matches what the Bulk Editing Rules editor accepts; for the equivalent API JSON format, see Set IP Rules.

Example 1: Priority Based on CIDR Specificity

Traffic to 192.168.0.0/16 is allowed; traffic to any other destination is denied. The /16 rule wins over /0 for matching addresses because it has the longer (more specific) prefix.

# cidr, protocol, fromPort, toPort, action
0.0.0.0/0, ALL, any, any, deny
192.168.0.0/16, ALL, any, any, allow

Example 2: Priority Based on Protocol Specificity

All TCP traffic is allowed; traffic using any other protocol is denied. The TCP rule wins over the ALL rule for TCP packets because a specific protocol is more specific than ALL.

# cidr, protocol, fromPort, toPort, action
0.0.0.0/0, ALL, any, any, deny
0.0.0.0/0, TCP, any, any, allow

Example 3: Priority Based on Port Specification

All TCP traffic is denied except TCP port 443 (HTTPS), which is allowed. The rule with a specific port wins over the rule that omits ports (which matches any port).

# cidr, protocol, fromPort, toPort, action
0.0.0.0/0, TCP, any, any, deny
0.0.0.0/0, TCP, 443, 443, allow

Example 4: Combining CIDR, Protocol, and Port Specificity

This rule set:

  • Allows TCP traffic to 192.168.0.0/16 on port 443
  • Denies all other TCP traffic to 192.168.0.0/16
  • Allows everything else

The narrowest rule (specific port + specific CIDR + specific protocol) wins for HTTPS to the subnet. The next-most-specific rule (specific CIDR + specific protocol + full port range) wins for other TCP to the subnet. The broadest rule applies to everything that didn't match the two above.

# cidr, protocol, fromPort, toPort, action
0.0.0.0/0, ALL, any, any, allow
192.168.0.0/16, TCP, 443, 443, allow
192.168.0.0/16, TCP, 0, 65535, deny
Was this page helpful?
Search Esc to close / Enter to view results