# Traffic Filtering Filter device traffic with configurable CIDR, protocol, port, and domain rules. The VPG **Traffic Filtering** option lets you control device-originated traffic with fine-grained rules. Compared to the simpler [Outbound Filter](https://docs.soracom.io/en/services/vpg/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. > [!NOTE] > > Traffic Filtering is available only on **Type-F**, **Type-G**, and **Type-F2** VPGs, and requires a separate contract. [Contact Soracom Support](https://docs.soracom.io/en/services/account/support#creating-a-support-request) 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](https://docs.soracom.io/en/services/vpg/traffic-filtering/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](https://docs.soracom.io/en/services/vpg/traffic-filtering/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](https://docs.soracom.io/en/services/vpg/traffic-filtering/configuration#examples). ## 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](https://docs.soracom.io/en/developers/glossary#session). Until then, each IoT SIM continues under the policy that was in effect when its current session started. > [!NOTE] > > 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](https://www.rfc-editor.org/rfc/rfc6598.txt) Shared Address Space reserved for Soracom [service endpoints](https://docs.soracom.io/en/developers/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](https://docs.soracom.io/en/services/vpg/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](https://docs.soracom.io/en/services/vpg/traffic-filtering/#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.