Using IPSec VPN to Provide Secure Remote Access for Mobile Users
In public places, such as hotels and airports, traveling staff or partners connect to the core network through an insecure access network or a public network such as the Internet to access internal resources of the core network. This process is called remote access. Security is a major concern in remote access. IPSec VPN can be deployed to establish an IPSec tunnel between a user terminal and the gateway of the core network. IPSec ensures secure and reliable data transmission.
Remote access scenarios include:
Remote Access of Mobile Users Using L2TP over IPSec
As shown in Figure 1, mobile users (such as traveling staff) use built-in VPN dial-up software of Windows or other dial-up software to access the enterprise network. L2TP provides the user authentication function, but no encryption function. To ensure security, deploy L2TP over IPSec and set up an L2TP over IPSec tunnel between the PC and enterprise gateway FW. Packets are encapsulated using L2TP and then encrypted using IPSec before being transmitted, ensuring communication security.
Access users are authenticated locally or remotely by the authentication server (RADIUS server, for example) in the headquarters. After authentication is successful, FW assigns private IP addresses within the headquarters network to users (PCs or mobile terminals).
Remote Access of Mobile Users or Wireless Terminals Using EAP
In an LTE scenario shown in Figure 2, wireless terminals access the headquarters network through a base station on an insecure network. The RADIUS server is located on the carrier's core network, so the gateway (FW) of the enterprise network needs to have the EAP relay function enabled. To prevent EAP packets from being eavesdropped, modified, or forged on the public network, IKEv2 negotiation provides authentication on the negotiation initiator in EAP mode to improve transmission security.
Remote Access of Mobile Users or Wireless Terminals Using DHCP over IPSec
In an LTE scenario shown in Figure 3, an eNodeB on an insecure access network needs to obtain a private IP address from the DHCP server on the aggregation network. The eNodeB uses this IP address to connect to the M2000, establish a temporary OM channel, and obtain OM configurations. The eNodeB and the DHCP server are not on the same network, so the gateway of the aggregation network needs to have the DHCP relay function enabled. To prevent DHCP messages from being eavesdropped, modified, or forged on the insecure access network, you can use IPSec to authenticate and encrypt DHCP messages to improve transmission security.
In this scenario, the gateway and the base station (DHCP client) must both support DHCP over IPSec.