L2TP over IPSec are unable to connect with more than 1 user in the same ISP

Network topology

Currently we facing issue that the L2TP/IPSec are unable to connect with more than 1 user in the same ISP. If 1 user already connected within the same ISP another user are unable to connect.

Like I have vpn user of A B C D. Those user are using different laptop but they all are within the same network / same Public IP, if user A has connected to the VPN, the user B C D couldn"t connect to the VPN server.

The establishment of the L2TP tunnel in Client-Initiated mode used on site is directly initiated by the LAC client (referring to the remote system that supports the L2TP protocol locally). After the LAC client has a public network address and can communicate with the LNS through the Internet, if an L2TP dial-up is triggered on the LAC client, the LAC client directly initiates an L2TP tunnel establishment request to the LNS without establishing a tunnel through the LAC device.

The l2tp over IPsec technology is that the inner layer messages are encrypted first with L2tp encapsulation and then with ipsec encapsulation. After L2tp encapsulation, the source ip address is the public ip to which the terminal belongs and the destination ip address is the firewall interface address, which leads to a consistent flow of interest during ipsec negotiation, resulting in the second ipsec not being able to negotiate successfully, so the second terminal computer cannot dial in.

The solution proposed at the beginning is that the terminal uses a different public network IP to dial in, or uses a simple L2tp dial. However, both solutions were unacceptable to customers, so we had to further consult with security expert engineers.

Security experts replied that if ipsec is in transport mode, it is true that you cannot access multiple clients at the same time, there are known limitations. But if you use tunnel mode is possible, and to enable Reverse Route Injection. Then try to verify in the laboratory and find that multiple clients use the same ISP address to access successfully.

1.      The ipsec encryption method should be changed to tunnel mode. (Since I didn"t find a way to modify the ipsec encryption method of the VPN client that comes with windows, so I used inode to dial the VPN and used the tunnel mode.)

As follow:

#

ipsec transform-set 1

 encapsulation-mode transport

 esp encryption-algorithm null

 esp authentication-algorithm sha1

#

ipsec transform-set 2

esp encryption-algorithm aes-cbc-128

esp authentication-algorithm sha1

#

ipsec transform-set 3

esp encryption-algorithm aes-cbc-256

esp authentication-algorithm sha1

#

ipsec transform-set 4

esp encryption-algorithm des-cbc

esp authentication-algorithm sha1

#

ipsec transform-set 5

esp encryption-algorithm 3des-cbc

esp authentication-algorithm sha1

#

ipsec transform-set 6

esp encryption-algorithm aes-cbc-192

esp authentication-algorithm sha1

#

2.      Configuring IPsec RRI

#

ipsec policy-template 1 1

transform-set 1 2 3 4 5 6

ike-profile 1

reverse-route dynamic

reverse-route preference 100

reverse-route tag 1000

#

The specific configuration is as attached, and the test results are as follows:

dis ike sa

    Connection-ID   Remote                Flag         DOI

------------------------------------------------------------------

    59              x.x.x.2/1042          RD           IPsec

    58              x.x..2/1044          RD           IPsec

Flags:

RD--READY RL--REPLACED FD-FADING RK-REKEY

dis l2tp session

LocalSID    RemoteSID    LocalTID    State

41960       11863        6284        Established

1657        11197        65107       Established

dis l2tp tu

dis l2tp tunnel

LocalTID RemoteTID State        Sessions RemoteAddress   RemotePort RemoteName

6284     1         Established  1        x.x.x.1         52100      vpn

65107    1         Established  1        x.x.x.2         49568      vpn

Client1

Client2

(1) Since the ip of the PC is not fixed, the firewall should use the template method to establish ipsec;

(2) The peer identity type in the ike profile can use the address type of all 0s, or use user-fqdn, fqdn, etc. After testing, it is found that the identifier configured on the inode is of the fqdn type, so this can be matched in the ike profile at the same time.

(3) Windows on the computer side can customize the algorithm parameters, and can configure enough ike proposal and transform-set so that the PC can match one of them, or open debugging ike all, and see the interaction parameters to set the algorithm;

(4) In this NAT traversal scenario, the inode must check NAT traversal to force the use of tunnel mode;

(5) The Reverse Route Injection needs to be enabled in the IPsec policy to generate a static route whose destination address is the protected peer private network, and the next hop is the peer address of the IPsec tunnel.