[Dr.WoW] [No.26] L2TP Client-initiated VPNs-part2

Latest reply: Aug 15, 2018 10:08:39 5020 3 0 0

4 Step 4: Data Encapsulation Transmission― Passing Through the Wormhole to Visit Earth

After the L2TP tunnel has been built, L2TP client data can freely go to and from the HQ network. Giving a clear explanation as to the process of how Professor Du passed through his wormhole is difficult, but it is not very difficult to explain how L2TP client data passes through the L2TP tunnel to reach the HQ network; this involves the encapsulation process for L2TP data packets. This process is very similar to GRE packets adopting and later discarding "alter-egos", with the difference being that the "alter-egos" are slightly different here.

[Dr.WoW] [No.26] L2TP Client-initiated VPNs-part2-1336615-1

 

The packet capture above shows the structure of L2TP packet encapsulation, and a more detailed ***ysis elucidates the encapsulation/decapsulation process for L2TP data packets in a client-initiated VPN scenario (Figure 1-3).

Figure 1-3 Process for client-initiated VPN packet encapsulation/decapsulation

[Dr.WoW] [No.26] L2TP Client-initiated VPNs-part2-1336615-2

 

The L2TP client's process for forwarding packets towards the internal network server is as follows:

1.         The L2TP client encapsulates the original packet using a PPP header, an L2TP header, a UDP header, and finally, on the outermost layer, a public network IP header, making this into an L2TP packet. The source address on the outer layer public network IP header is the L2TP client's public network IP address, while the destination address is the LNS's public network interface's IP address.

2.         L2TP packets pass through the Internet to the LNS.

3.         After the LNS receives the packets, it completes identity authentication and packet decapsulation in the L2TP module, discarding the PPP header, the L2TP header, the UDP header and the outer layer IP header, to restore the original packet.

4.         The original packet carries only an inner-layer private network IP header. This inner-layer private network IP header's source address is the private network IP address obtained by the L2TP client, while the destination address is the private network IP address of the internal network server. The LNS checks its routing table based upon the destination address, and then forwards the packet using the matching routing result.

The L2TP client now has obstacle-free access to the HQ internal network server, but there is still a problem: how do return packets from HQ's internal network server bound for the L2TP client enter the tunnel to return to the L2TP client? We don't seem to have configured any route to guide these return packets into the tunnel, right? A look at the routing table on the LNS shows something interesting: the LNS has automatically issued a host route for the L2TP client that obtained the private network IP address.

[LNS] display ip routing-table                                       

Destination/Mask    Proto  Pre  Cost     Flags NextHop         Interface       

    192.168.2.2/32  Direct 0    0           D    192.168.2.2     Virtual-Template1

This automatically generated host route is a user network route (UNR), the destination address and the next-hop are both the private network address that the LNS assigned for the L2TP client, and the sending interface is the VT interface. This route is the LNS's wormhole entrance, and guides packets bound for the L2TP client into the tunnel. Our question has been resolved, and it should now be easy to understand the forwarding process for return packets from the internal network server.

1.         After the LNS receives a return packet from the internal network server, it checks for a route based upon the packet's destination address (the L2TP client's private network IP address), selects a UNR route, and sends the return packet to the VT interface.

2.         The return packet is encapsulated with a PPP header, an L2TP header, a UDP header, and an outer-layer public network IP header in the L2TP module.

3.         The LNS checks the routing table based upon the packet's outer-layer IP header's destination IP address (the L2TP client's public network IP address), and then forwards the packet using the matching routing result.

The above process is a bit complicated, as return packets must be matched twice to the routing table on their trip back to the L2TP client.

Our above explanation only used one L2TP client, but in real-world environments there will be many L2TP clients accessing the HQ network through the wormhole simultaneously. If the L2TP client is not satisfied with only accessing the HQ network, but also wants to access other L2TP clients (this is to say, if there is to be mutual access between L2TP clients), can L2TP achieve this? Don't forget, the LNS is the transfer station that connects multiple wormholes, and it has host routes to many L2TP clients. Therefore, two L2TP clients can freely access each other through LNS forwarding, as shown in Figure 1-4. Of course, the premise for mutual access is that each L2TP client must know the IP address assigned by the LNS for each other. This premise is not very easily achieved, so scenarios with mutual access between L2TP clients are not very common.

Figure 1-4 L2TP client mutual access scenario

[Dr.WoW] [No.26] L2TP Client-initiated VPNs-part2-1336615-3

 

5 Approach to Security Policy Configuration

The overall approach to configuration of security policies for L2TP client-initiated VPNs is similar to that for configuration of GRE security policies, except that the tunnel interface has been replaced by the VT interface.

As shown in Figure 1-5, in our hypothetical scenario, the LNS's GE0/0/1 is connected to the HQ private network, and belongs to the Trust zone; GE0/0/2 is connected to the Internet, and belongs to the Untrust zone; the VT interface belongs to the DMZ zone; the IP address assigned by the LNS for the L2TP client is 192.168.2.2.

Figure 1-5 Network organization for configuring client-initiated VPN security policies

[Dr.WoW] [No.26] L2TP Client-initiated VPNs-part2-1336615-4

 

The process for configuring a security policy is as follows:

1.         We first configure the broadest possible interzone security policy to assist L2TP VPN adjustments/testing.

The interzone default packet filtering action on the LNS is set to "permit":

[LNS] firewall packet-filter default permit all

2.         After L2TP configuration, we ping the internal network server with the L2TP client, and then check the session table.

[LNS] display firewall session table verbose                         

 Current Total Sessions : 2                                                    

  l2tp  VPN:public --> public                                                  

  Zone: untrust--> local  TTL: 00:02:00  Left: 00:01:58                        

  Interface: InLoopBack0  NextHop: 127.0.0.1  MAC: 00-00-00-00-00-00           

  <--packets:20 bytes:1120   -->packets:55 bytes:5781                          

  1.1.1.2:1701-->1.1.1.1:1701                                                   

                                                                               

  icmp  VPN:public --> public                                                  

  Zone: dmz--> trust  TTL: 00:00:20  Left: 00:00:01                            

  Interface: GigabitEthernet0/0/1  NextHop: 192.168.1.2  MAC: 20-0b-c7-25-6d-63

  <--packets:5 bytes:240   -->packets:5 bytes:240                              

  192.168.2.2:1024-->192.168.1.2:2048

The above information shows that the L2TP client successfully pinged the internal network server, and that an L2TP session has been created.

3.         ***ysis of the session table shows the existing conditions to which a refined security policy can be matched.

From the session table we can see two streams (one being Untrust-->Local L2TP packets, and the other DMZ-->Trust ICMP packets), and we therefore can obtain the direction of packets on the LNS, as shown in Figure 1-6.

Figure 1-6 LNS packet direction

[Dr.WoW] [No.26] L2TP Client-initiated VPNs-part2-1336615-5

 

The above figure shows that the LNS needs to configure a DMZ-->Trust security policy that allows packets from the L2TP client seeking access to the internal network server to pass, and also needs to configure an Untrust-->Local security policy to allow the L2TP client and the LNS to establish an L2TP tunnel.

After the L2TP tunnel is established, the direction of return packets sent from the internal server to the L2TP client is the opposite of when the L2TP client accesses the internal server, and we therefore do not need to elaborate further about this.

To summarize, the security policies that should be configured on the LNS under various conditions are shown in Table 1-5, and we should configure the security policies that best match existing conditions.
Table 1-5 Selecting LNS security policies based upon existing conditions

Transactional Direction

Source Security Zone

Destination Security Zone

Source Address

Destination Address

Used in

The L2TP client accesses the internal network server

Untrust

Local

ANY

1.1.1.1/32

L2TP

DMZ

Trust

192.168.2.2~192.168.2.100

(address pool addresses)

192.168.1.0/24

*

The internal network server accesses the L2TP client

Trust

DMZ

192.168.1.0/24

192.168.2.2~192.168.2.100

address pool addresses

*

*: Use in this instance is related to the transaction type, and can be configured according to actual circumstances (for example: TCP, UDP, and ICMP).

 

 

NOTE

In this scenario, the LNS only passively receives the request from the L2TP client to establish a tunnel, but will not actively initiate a request to the L2TP client to establish a tunnel, so only an Untrust-->Local security policy needs to be configured on the LNS for the L2TP tunnel.

Therefore, in L2TP VPN scenarios using the client-initiated method, the LNS's VT interface must be added to a security zone, and the security zone the VT interface belongs to determines the direction of packets on the firewall. If the VT interface belongs to the Trust zone, then no DMZ-Trust interzone security policy is necessary, but this also involves security risks. Therefore, it is advisable to add the VT interface to a separate security zone, and then configure the security policy that best matches the existing conditions.

4.         Finally, the default packet filtering's action is changed to "deny".

[LNS] firewall packet-filter default deny all

 

 

To view the list of all Dr. WoW technical posts, click here.

  • x
  • convention:

user_2790689
Created Jun 29, 2015 08:18:47 Helpful(0) Helpful(0)

Thank you.
  • x
  • convention:

Abulaynain
Created Aug 15, 2018 09:52:44 Helpful(0) Helpful(0)

Regarding this step:
"source address on the outer layer public network IP header is the L2TP client's public network IP"
....How the client can know it's network public IP while it's supposed to be changed dynamically
  • x
  • convention:

Mysterious.color
MVE Created Aug 15, 2018 10:08:39 Helpful(0) Helpful(0)

very good

thank you for this well written article
  • x
  • convention:

Core%20Engineer%2C%20Technical%20Department.%20High%20experience%20in%20Networking

Reply

Reply
You need to log in to reply to the post Login | Register

Notice Notice: To protect the legitimate rights and interests of you, the community, and third parties, do not release content that may bring legal risks to all parties, including but are not limited to the following:
  • Politically sensitive content
  • Content concerning pornography, gambling, and drug abuse
  • Content that may disclose or infringe upon others ' commercial secrets, intellectual properties, including trade marks, copyrights, and patents, and personal privacy
Do not share your account and password with others. All operations performed using your account will be regarded as your own actions and all consequences arising therefrom will be borne by you. For details, see " Privacy."
If the attachment button is not available, update the Adobe Flash Player to the latest version!
Login and enjoy all the member benefits

Login and enjoy all the member benefits

Login