Definition
Firewall (Firewall) implements access control at the network boundary, allowing or denying traffic based on predefined rules (ACL, security policy). It is a core component of boundary protection in security architecture. In IoT scenarios, firewalls can protect enterprise intranets, private network gateways, cloud platform entrances, VPN tunnel endpoints, etc., preventing unauthorized access, DDoS, and intrusions. They work together with IPSec, TLS, access authentication, etc., to build defense in depth.
Types and Capabilities
- Packet Filtering: Based on IP, port, and protocol quintuple filtering, simple and efficient
- State Detection: Tracks connection states, only allows return traffic for established connections, prevents spoofed packets
- Application Layer Gateway (ALG): Deep packet inspection (DPI), identifies application protocols (such as MQTT, HTTP), supports application-level policies
- NAT/NAPT: Address translation, hides internal network topology, conserves public IP addresses
IoT Scenario Strategy
The IoT platform firewall needs to be configured according to the characteristics of device access: whitelist IP/port, limit devices to access only designated APIs, isolate lateral traffic between devices, and rate-limit to prevent abuse. The private network gateway firewall, combined with RADIUS authentication, implements differentiated policies based on users/devices. Scenarios such as Industrial IoT must comply with MLPS (Multi-Level Protection Scheme) and industrial control security regulations.
Typical Use Cases
Enterprise network boundary, IoT platform access layer, private network gateway, cloud security groups, connected vehicleTSP platform, etc. The SimtoLink cloud platform deploys firewall policies at the access layer to ensure secure isolation between devices and business operations.
The SimtoLink cloud platform deploys firewall policies at the access layer to ensure secure isolation between IoT devices and enterprise applications. Combined with VPDN and dedicated APN, SimtoLink can build an in-depth defense system from terminal to cloud for customers. SimtoLink supports customizing access control rules according to client requirements to meet the security compliance needs of scenarios such as Industrial IoT.
If the state-table age is shorter than the heartbeat, the connection is torn down
A stateful firewall remembers who opened a connection and allows return packets that belong to that table. An entry is deleted after it has been idle for a while. If an IoT heartbeat is longer than that idle time, the next report is treated as a new connection. If the policy allows only return traffic on an established connection and does not allow the device to open one, the report is dropped outright. The symptom is that a fresh connection works, and after a silent stretch only a device restart restores it. Compare the heartbeat interval with the firewall session timeout. The timeout must be longer than the heartbeat, and shorter than the resource hold the service can allow.
Some devices hold one connection while they wait for a downlink command and rarely send anything themselves. To the firewall that connection looks idle the whole time. Either have the device send a keepalive before the timeout, or lengthen the session timeout for that port alone. Lengthening every session globally lets finished connections keep table entries. When the table is full, a new device cannot enter.
Open a port and forget the direction, and devices scan each other
A five-tuple rule should at least name the source, the destination, the port, and the direction that may open the flow. If it only says “allow this port,” devices on the same private network can reach that port on each other. One compromised sensor can scan its neighbors. The usual correct direction for an IoT platform is the device reaching a platform address that was named. The platform should not be a way for a device to reach an arbitrary intranet. Lateral traffic should be denied by default. If devices must talk to each other, open that peer address on its own.
Application identification can recognize a messaging protocol, but the policy needs a clear default when identification fails. A default of allow lets an unknown protocol bypass the port limit. A default of deny requires every firmware report to be recognized first. After a protocol upgrade or a port change, prove the identification rule in a test zone before moving it to production, so a whole batch of devices is not denied by the default at once.
Address translation leaves an inbound callback outside the gateway
Network address translation lets many devices share a few public addresses. The outside cannot see a device’s real address. If the platform calls back when the device has not sent a packet first, there is no matching translation entry, and the callback never reaches the device. When downlink is required, keep a connection opened from the inside outward, or use a push channel on the platform side, rather than having the platform dial the device’s private address. Writing the translated public address into the device callback address fails the callback as soon as that address changes.
Both a SimtoLink private network and the cloud-platform access layer can hold access control, but the objects on the two sides differ. The card and the private-network gateway decide whether the device may enter the enterprise address range. The cloud-platform firewall decides which interfaces the device may call. If the card already has an intranet address and the interface is still refused, check the destination port and the direction on the platform or enterprise firewall, not a card reactivation. A policy change should keep deny logs. “The network is down” alone cannot separate a missing route from a rule that dropped the packet.
The drop time in the log is earlier than the application alarm
A firewall drop does not always notify the sender at once. The device waits for its own retransmission timeout before it treats the attempt as failed, so the drop time in the log is earlier than the application alarm, by one timeout period. Count that gap when reconciling, or the two will look like different faults. A log should at least have the source address, the destination address, the port, the protocol, and the name of the rule that matched. The words “dropped” alone cannot tell a wrong direction, a missing state-table entry, or an application identification that did not recognize the protocol.
If a rule is changed while a session is in progress, an existing entry may keep passing until it ages out, while a new connection is bound by the new rule at once. The same device then looks fine on the old connection and fails after reconnect, which looks like an intermittent fault. After a change, clear the related entries or wait for them to age, then run acceptance. Policy changes on a SimtoLink private-network gateway and on the cloud platform should both keep a rule version. If the card address is dynamic and the rule is still written as the address from the previous round, the reconnect is refused. When the address changes, update the rule by device identity, rather than opening the whole subnet forever.