Troubleshooting
For an overview of Traffic Filtering, see Traffic Filtering. To configure Traffic Filtering, see Configuration. For behavior details that may explain unexpected results, also see Usage Notes, Forwarding by Platform Services Is Out of Scope, and What Domain Filtering Cannot Control.
Traffic from a Device Is Unexpectedly Blocked
- Confirm that the device's IoT SIM is assigned to the VPG on which Traffic Filtering is configured.
- Confirm that Traffic Filtering is enabled on the VPG. If it is disabled, no rules are applied, but if it was just disabled, data sessions may not yet have picked up the change.
- Check that the VPG is a supported type (see Limitations).
- Confirm that an allow rule exists that matches the destination (CIDR or FQDN), protocol, and port.
- Confirm that you clicked Save below the list; rules added in the User Console are not applied until saved.
- Re-establish the device's data session to apply the latest rules (see When Rule Changes Take Effect).
- If Outbound Filter is also configured on the VPG, confirm that it does not have a deny rule matching the traffic; Outbound Filter rules are evaluated after Traffic Filtering and can block traffic that a Traffic Filtering allow rule permits.
Traffic from a Device Is Unexpectedly Allowed
- Confirm that the device's IoT SIM is assigned to the VPG on which Traffic Filtering is configured.
- Confirm that Traffic Filtering is enabled on the VPG. If it is disabled, all traffic passes without filtering.
- Check for overly broad allow rules, such as the default
allow 0.0.0.0/0rule added automatically when Traffic Filtering is first enabled (see Default Rule). - Confirm that you clicked Save below the list; a deny rule that has not been saved is not yet applied.
- Re-establish the device's data session to apply the latest rules (see When Rule Changes Take Effect).
- Confirm that the device is not using encrypted DNS. If the device uses DoH or DoT, the platform cannot read DNS queries, so domain rules generate no dynamic IP rules and domain filtering does not apply (see DNS Resolution and Dynamic Rules).
A Rule Was Rejected on Save
| Condition | HTTP status | Cause and resolution |
|---|---|---|
Traffic filtering is not allowed for operator <operator> |
403 | See When Traffic Filtering Is Not Enabled for Your Operator below. |
| Unsupported VPG type | 400 | The VPG is not a supported type (see Limitations). |
| IP or domain rule count exceeds 500 per VPG | 400 | Capped at 500 per type. Consolidate CIDR ranges or use wildcards to reduce the count. |
| Rule specifies an IPv6 address | 400 | Use IPv4 only. |
| Invalid FQDN pattern | 400 | The pattern exceeds 255 characters; the wildcard label is not standalone (e.g., *foo.example.com); the wildcard appears in a non-leading label; more than one wildcard label is used; or the pattern contains consecutive dots. See Domain Rules and Limitations. |
Invalid fromPort / toPort |
400 | fromPort must not exceed toPort; both must be in 0–65535. See Protocol and Port Semantics. |
| Missing required field | 400 | Each IP rule requires cidr, protocol, and action; each domain rule requires fqdnPattern, protocol, and action. |
deny action on a domain rule |
400 | Domain rules support only action: "allow". |
| Duplicate rule | 400 | Identical rules in the same payload are rejected. Remove duplicates before saving. |
When Traffic Filtering Is Not Enabled for Your Operator
Symptoms: the Traffic Filtering section (under the Filtering tab) shows a contract-required notice, the section reports Traffic Filtering is not available for this VPG type., the API returns Traffic filtering is not allowed for operator <operator>, or the enable API (POST /v1/virtual_private_gateways/<VPG-ID>/traffic_filtering/enable) returns 403 Forbidden. Traffic Filtering requires a separate contract. Contact Soracom Support to apply.