Definition
VPDN (Virtual Private Dial-up Network) is a virtual private network technology based on the carrier cellular network. When IoT SIM cards access through VPDN, data is transmitted to the enterprise intranet or designated server via the carrier's dedicated channels (tunnels such as L2TP, GRE, etc.), isolated from the public network. Fixed IP, IP whitelist, and access control can be configured to ensure data security and meet compliance requirements such as MLPS (Multi-Level Protection Scheme), HIPAA, GSP, etc.
VPDN, used in conjunction with a dedicated APN, achieves logical isolation between terminals and the platform. It is suitable for industry scenarios with clear requirements for data security and network isolation.
Technical Features
VPDN uses tunnel encryption, and data does not pass through the public network. It supports fixed IP allocation, which facilitates firewall configuration on the platform side. It can be combined with VPN, TLS, and other methods to enhance security. IoT SIM cards need to enable VPDN function and connect with the enterprise's LNS (L2TP Network Server) or carrier gateway.
Use Cases
VPDN is widely used in scenarios with high data security requirements such as smart healthcare, smart grid, intelligent manufacturing, smart drug supervision, and government affairs. Medical HIS, PACS, power grid SCADA, industrial MES, and drug supervision traceability require dedicated network isolation. SimtoLink provides one-stop services for the above scenarios, including VPDN configuration, dedicated APN, and real-name verification.
The tunnel endpoint decides which side the traffic stops on
A virtual private dial-up network means that after the IoT SIM attaches, the user plane is sent into the tunnel between the carrier and the enterprise, comes out at the enterprise tunnel endpoint, and enters the enterprise address space. The usual tunnels are a Layer 2 tunnel or generic routing encapsulation. The address the terminal receives comes from a pool the enterprise planned, or from a fixed assignment. The platform reaches the device at that private address, and the device uses it to reach servers on the intranet. The public internet does not see this SIM's service address. If the tunnel never comes up, attach can still look normal, while service traffic never reaches the server behind the enterprise firewall.
The tunnel endpoint, the address pool, and the access settings on the SIM have to be three items on the same provisioning order. After the endpoint address or the account changes, the old tunnel leaves a half-open session on the carrier side: the module dials again and again, and the enterprise side never sees the peer. If the address pool overlaps the office network or the shop-floor network, a device address inside the tunnel collides with a computer on site, and routing works and then fails. If name resolution still points at a public recursive server, the service address is private but the device has to leave the private network before it can resolve a name. A failed lookup is then mistaken for a broken tunnel.
A fixed address, authentication, and access control take effect together
A fixed private address for the SIM is needed only when the platform must connect to the device, and that address has to be written into what the firewall allows. Assigning the address without opening the port leaves the device online and the service still refused. Opening the port while the address changes every time makes the rule expire at the next attach. Authentication has to finish when the tunnel is built. The account, the domain, and the shared secret have to match the enterprise gateway. An extra space on the SIM side, or a wrong domain, often shows up only as a timeout. Access control should allow by device group rather than by a whole address block, so a SIM that has been reassigned cannot still reach the entire intranet.
A tunnel separates traffic from public address space. It does not by itself mean the payload is encrypted. Without an extra security encapsulation, what is isolated is the path. Sensitive services should still be encrypted at the application layer. The maximum transmission unit has to be reduced by the tunnel overhead. Otherwise short messages work, large messages go silent, a firmware update or a certificate download stalls halfway, and the daily heartbeat keeps succeeding. The relationship to APN is this: the access point decides which network is entered, and the virtual private dial-up network decides that the user plane of that network lands in the enterprise tunnel. Both have to be provisioned. Changing one name does not create the other.
What it looks like when only the access-point name was changed
The field often stops at "the private-network access point is already written on the SIM, so it should be secure." If that access point is only a name that still exits to the public internet, the next hop is still a public gateway, and this device never appears in the enterprise firewall. The check is whether the address the device received belongs to the agreed private range, and whether the tunnel monitor on the enterprise side has a matching session, not whether the module's attach lamp is on. The reverse also happens: the tunnel session is still there, the SIM has been suspended or is out of credit, the session is an empty shell, a new attach cannot enter, and the old session stays until it times out.
When many SIMs share one account and the address pool is too small, a device that comes online later pushes out the address of one that came online first. The platform still sends commands to the old address, and the command lands on another device. After roaming is restricted by region, a device taken to another province fails to attach. If the failure policy falls back to a public access point, the private network is bypassed without anyone saying so. For a network boundary related to MLPS, someone has to be able to say which enterprise gateway the user plane terminates on, and whether the log for that session can be retrieved by SIM identity. A "private network" whose termination point cannot be stated will, in an inspection, be treated as ordinary cellular internet.
After the enterprise side sees a tunnel session, it still has to check that the address in the session is the address agreed for this SIM. The right address with the port not opened still leaves the service unreachable, and restarting the module again and again does not show why. Key or certificate rotation should be done in batches. If every SIM redials in the same minute, sessions at the tunnel endpoint fill up, and devices that dial later attach but receive no address. If a device that receives no address automatically switches to a public access point, the monitor still shows a private-network session for a short time while the service has already left by another exit. The attach log should record the access-point name used this time, so it is possible afterward to confirm the wrong one was not taken.