Definition
IPSec (IP Security) is an IP layer security protocol suite defined by the IETF, providing data encryption, integrity verification, and authentication. It is often used with L2TP for private network VPDN (L2TP over IPSec), and can also be used alone for site-to-site VPNs. It supports transport mode (encrypting only the payload) and tunnel mode (encapsulating the entire IP packet), complementing TLS to provide transport layer and network layer security.
Core Components
- AH (Authentication Header): authentication only, no encryption, rarely used
- ESP (Encapsulating Security Payload): encryption + authentication, supports AES-GCM, AES-CBC, etc., mainstream solution
- IKE/IKEv2: key exchange protocol, negotiates SA (Security Association), DH keys, authentication
Deployment Mode
Transport mode is used for end-to-end encryption; tunnel mode is used for gateway-to-gateway VPN. IoT private network scenario: devices or gateways establish IPSec tunnels with LNS, and data is encrypted and transmitted over the public network to the enterprise intranet. IPSec over NAT requires NAT-T (UDP 4500) support.
Typical Use Cases
Enterprise VPN, private network tunnels, site interconnection, secure backhaul of IoT devices, etc. SimtoLink's VPDN solution uses L2TP+IPSec to build secure tunnels.
SimtoLink's VPDN private network solution uses L2TP+IPSec to build secure tunnels. When IoT devices access the enterprise intranet via the public network, data is encrypted and authenticated via IPSec to prevent eavesdropping and tampering. SimtoLink can provide IPSec-based end-to-end encrypted connection solutions for customers with high security requirements, such as industrial IoT and financial payment services.
After a security association expires, traffic stops in renegotiation
IPsec does not write a key into a configuration file and use it forever. A pair of security associations states the algorithms, the keys, and the lifetime. The lifetime can be by time or by traffic volume. When it expires, the two sides negotiate a new set with a key exchange. If there is no overlapping association in parallel during negotiation, packets that are being sent fail or are buffered. If an IoT gateway happens to report at the expiry instant, the application sees a short timeout and then recovers on its own. To see whether it is a lifetime problem: the gap between the failure time and the association setup time is stable, and the peer log shows negotiation at the same time, not only a timeout on one side.
The algorithm suites on the two sides must overlap. If one side accepts only a newer combination and the other offers only an old combination, negotiation fails and the tunnel stays at “being established.” Encryption strength is not “automatically the weaker of the two.” There is simply no association. Print the proposal list at both ends, rather than only checking whether the pre-shared key matches. If the keys match and the proposal is empty, the symptom is the same: the tunnel does not come up.
Tunnel mode hides the original address inside an outer header
Transport mode protects only the upper-layer payload. The outer addresses are still the real parties, which suits host to host. Tunnel mode wraps the whole original packet in a new network-layer header. The outer addresses are the two gateways. The inner addresses are the device and the enterprise server. Private-network backhaul almost always uses tunnel mode, so routing on the public network does not have to know the device’s private address. A capture that looks only at the outer header seems to show traffic between two gateways. While troubleshooting, match address and port again on the decrypted inner header.
Selectors decide which inner traffic enters the tunnel. A selector that is too wide mixes management traffic and service traffic in one association, and a policy change on one side interrupts the other. A selector that is too narrow keeps a newly added server address out of the tunnel. The intranet route exists and that particular address does not pass. When a server is added, change the selector and the firewall together. Changing only the routing table is not enough.
Crossing address translation means switching to the agreed encapsulation port
After encryption, the transport-layer port is invisible to an address-translation device in the middle. Some translators drop the packet or cannot keep the mapping. The way through translation is to wrap another user datagram on the outside and use an agreed port, so the translator keeps a table entry on that port. If only one side turns traversal on, and the other still listens for the pure security protocol, negotiation fails after the first phase. Whenever the path has operator or enterprise address translation, assume this encapsulation is required, rather than trying it only after a failure.
A SimtoLink virtual private network often pairs a Layer-2 tunnel with IPsec. What it protects is the public-network stretch from the access gateway to the enterprise gateway. Air-interface encryption still exists on its own. The keys differ, and the endpoints differ. If the card has already attached and tunnel negotiation fails, check the association proposal, the selector, and the traversal encapsulation, not a card reactivation. If the tunnel is up and a particular port is not, leave IPsec and check the firewall behind the selector. Keepalive packets must be shorter than the translation-table timeout on the path, or the mapping disappears and the next service packet has to negotiate again.
When traffic does not hit an interesting flow, the tunnel can still be up
A security association that is established only means the two ends agreed on algorithms and keys. Which packets enter the tunnel is decided by the selectors of the interesting traffic. If the probe’s address or port is not in the selector, it follows the default route and does not enter the tunnel. The enterprise intranet on the far side never receives it, and diagnostics still show the tunnel as connected. Probe with the same address and port as the service, or temporarily write the probe traffic into the selector. Pinging from another computer whose address is not in the selector does not prove the tunnel is broken, and it does not prove the service address is open.
A selector that is too broad also sends the gateway’s own management traffic into the tunnel. The management plane then depends on the tunnel, and tunnel negotiation depends on the management plane. When the association expires, both sides lose contact. Management addresses should be kept out of the interesting traffic, with a maintenance path that does not depend on that tunnel. Up or down on a SimtoLink virtual private network has to be read from the association state and the selector hit count together. If the association is green and the hit count does not rise, the service address or port is not in the selector yet. Replacing the IoT SIM card will not raise the hit count. What changes is policy, not the subscriber identity.