Traffic Filtering
The VPG Traffic Filtering option lets you control device-originated traffic with fine-grained rules. Compared to the simpler Outbound Filter, Traffic Filtering can match on destination CIDR and protocol/port, as well as on destination FQDN (domain name), making it suitable for allow-list use cases such as restricting devices to a small set of cloud APIs.
Traffic Filtering is available only on Type-F, Type-G, and Type-F2 VPGs, and requires a separate contract. Contact Soracom Support to apply.
VPG Type-G has the same functionality as Type-F. On this page, references to Type-F apply equally to Type-G.
Filtering Types
A Traffic Filtering configuration uses two independent rule sets.
IP Rules
Each IP rule matches outbound traffic by destination IPv4 CIDR and allows or denies the matched traffic. You can additionally narrow the match by protocol (TCP (6), UDP (17), ICMP (1), or any IANA protocol number from 0 to 255) and, where applicable, by port range.
For rule priority and examples, see IP Rules.
Domain Rules
Each domain rule matches outbound traffic by destination FQDN (domain name) and allows the matched traffic (the action is always allow). You can additionally narrow the match by protocol and port. Patterns may use a single leading wildcard label (*.example.com).
For wildcard patterns, rule priority, and DNS resolution behavior, see Domain Rules.
Configuration Examples
Traffic Filtering supports configurations such as the following.
| Goal | Example |
|---|---|
| Allow only HTTPS | Add an IP rule allowing TCP/443 to all destinations: 0.0.0.0/0, TCP, 443, 443, allow |
| Allow only specific API servers | Use IP rules for known CIDR ranges, and domain rules for FQDN patterns such as *.soracom.io, TCP, 443, 443 |
| Allow DNS and NTP | Add IP rules for your DNS server (UDP/53) and NTP server (UDP/123) |
| Migrate from an old system to a new one | Allow both old and new API FQDNs with domain rules; remove the old FQDN rule after migration |
For detailed configuration examples, see Configuration.
Usage Notes
When Rule Changes Take Effect
Traffic Filtering changes (enabling, disabling, and rule edits) take effect per IoT SIM when that IoT SIM establishes a new data session. Until then, each IoT SIM continues under the policy that was in effect when its current session started.
Plan for a data session re-establishment when rolling out a new configuration. The re-establishment may also cause a brief interruption to traffic, as data sessions may be reassigned across the VPG infrastructure. Applications that rely on persistent TCP connections should implement auto-reconnect logic.
Implicitly Allowed Traffic
Traffic destined to 100.64.0.0/10 (the RFC 6598 Shared Address Space reserved for Soracom service endpoints such as Metadata, DNS, and NTP) is always allowed.
Default Rule
When Traffic Filtering is first enabled on a VPG, a permissive default rule (allow 0.0.0.0/0) is added automatically for IP rules so that existing traffic is not blocked while you build up your allow-list. Remove or replace this default rule once your intended rule set is ready.
Protocol and Port Semantics
The meaning of fromPort and toPort depends on the protocol (matching AWS Security Group conventions):
| Protocol | fromPort |
toPort |
Notes |
|---|---|---|---|
| TCP (6), UDP (17) | Port range start | Port range end | Specify 0/65535 (or any/any) to match any port. Both values must be in 0-65535 and satisfy fromPort <= toPort. |
| ICMP (1) | ICMP type | ICMP code | Each in 0-255 (AWS Security Group convention: fromPort is the ICMP type, toPort is the code). Specify any/any to match any ICMP, e.g., Echo Request (8, 0). |
| Port-less protocols (ICMPv6=58, GRE=47, ESP=50, AH=51, ANY=255, ...) | (none) | (none) | Omit both, or use the explicit full range 0/65535. Other concrete values are rejected. |
Limitations
| Item | Limit |
|---|---|
| IP Rules per VPG | 500 |
| Domain Rules per VPG | 500 |
| FQDN pattern length | 255 characters (for internationalized domain names, the limit applies to the Punycode-encoded form) |
| IP version | IPv4 only |
| Supported protocols | TCP, UDP, ICMP, or any IANA protocol number 0-255 (255 = ANY). Applies to both IP and domain rules. |
| Supported VPG types | Type-F, Type-G, Type-F2 |
Forwarding by Platform Services Is Out of Scope
Traffic Filtering applies to traffic that leaves the device through the VPG. When you use Soracom Platform Services such as Soracom Beam, Funnel, or Funk, both IP and domain rules govern only the traffic from the device to the Platform Service; they do not apply to the onward traffic from the service to the destination you configured.
For example, if Soracom Beam forwards to customer.com, a rule that allows or denies customer.com has no effect on Beam's forwarding to customer.com.
Using Traffic Filtering Alongside Outbound Filter
Traffic Filtering and the Outbound Filter can coexist on the same VPG. In the User Console, both appear under the Filtering tab: Outbound Filter is the Outbound Routing Filter section and Traffic Filtering is the Traffic Filtering section. When both are configured:
- Two independent rule engines: Traffic Filtering rules are evaluated before Outbound Filter rules. Because both engines act on VPG egress, keep the two rule sets consistent: traffic you intend to allow must be permitted by both, and an intended deny in one engine should not be contradicted by an allow in the other.
- Recommendation: For new deployments, we recommend using Traffic Filtering rather than Outbound Filter. Traffic Filtering supports FQDN-based rules, protocol- and port-level matching, and most-specific-match priority, giving you more granular control than Outbound Filter (which matches on CIDR only).
Best Practices
Apply the Principle of Least Privilege
Start from a deny-all posture (no IP rules) and add allow rules only for the destinations and protocols your application actually needs. Avoid broad rules such as 0.0.0.0/0 with protocol ANY.
Be Careful with Wildcards
A pattern like *.example.com matches every single-level subdomain under example.com (for example, api.example.com and www.example.com), which may be more permissive than you intend.
Test in a Staging Environment
Verify new rules against a test VPG before applying them to production. Schedule changes during a maintenance window and consider applying them to a subset of devices first. See When Rule Changes Take Effect for why a session re-establishment is needed.
Be Mindful of the Rule Limit
IP rules and domain rules are each capped at 500 per VPG. Consolidate CIDR ranges or use wildcard FQDN patterns to keep the rule count manageable. Periodically review and remove rules that are no longer needed.