[Dr.WoW] [No.45] Configuring SSL VPN Security Policies Highlighted

Latest reply: Oct 29, 2015 03:18:02 2968 1 0 0

The approach to configuring SSL VPN security policies is similar to that with IPSec, as we first configure a relatively permissive security policy on the firewall, to guarantee that SSL VPN services run normally, and then obtain refined security policy match conditions through ***yzing the session table. For the specific process refer to the introduction in "IPSec VPNs".

Below I'll detail separate security policy configuration processes for two kinds of scenarios―Web proxy/file sharing/port forwarding scenarios and network extension scenarios.

1 Configuring Security Policies for Web Proxy/File Sharing/Port Forwarding Scenarios

The purpose of configuring security policies in Web proxy, file sharing and port forwarding scenarios is to achieve network layer interworking. To learn more about conducting permission control over remote user resource access, please refer to the content we introduced above regarding "resource authorization"

In our example here, an SSL VPN tunnel is established between a remote user and firewall FW (here we'll use the file sharing access service as an example), with the remote user accessing the file server, as shown in Figure 1-1. We'll assume that on FW the GE0/0/1 interface is connected to the private network and belongs to the DMZ Zone, and that the GE0/0/2 interface is connected to the Internet and belongs to the Untrust Zone.

Figure 1-1 SSL VPN file sharing

[Dr.WoW] [No.45] Configuring SSL VPN Security Policies-1314675-1

 

After the remote user successfully initiates access to the server, the following session table can be seen on FW.

<FW> display firewall session table verbose

 Current Total Sessions : 4                                                    

  https  VPN:public --> public  ID: a48f3629814102f62540ade7f                  

  Zone: untrust--> local  TTL: 00:10:00  Left: 00:09:52                          

  Output-interface: InLoopBack0  NextHop: 127.0.0.1  MAC: 00-00-00-00-00-00    

  <--packets:436 bytes:600276   -->packets:259 bytes:32089                     

  4.1.64.179:41066-->4.1.64.12:443   //packet establishing SSL VPN tunnel

                                                                               

  https  VPN:public --> public  ID: a48f3629815b06fd6540ade7f                  

  Zone: untrust--> local  TTL: 00:10:00  Left: 00:09:52                          

  Output-interface: InLoopBack0  NextHop: 127.0.0.1  MAC: 00-00-00-00-00-00    

  <--packets:291 bytes:395991   -->packets:176 bytes:26066                     

  4.1.64.179:41067-->4.1.64.12:443   //packet establishing SSL VPN tunnel    

                                                                               

  tcp  VPN:public --> public  ID: a48f3629818f0c229540ade8d                     

  Zone: local--> dmz  TTL: 00:00:10  Left: 00:00:02                          

  Output-interface: GigabitEthernet0/0/1  NextHop: 4.0.2.11  MAC: 78-ac-c0-ac-93-7f  <--packets:5 bytes:383   -->packets:8 bytes:614                              

  4.0.2.1:10013-->4.0.2.11:445       //packet from firewall (serving as the client) accessing the server

                                                                               

  netbios-session  VPN:public --> public  ID: a58f3629817501ad8a540ade8d        

  Zone: local--> dmz  TTL: 00:00:10  Left: 00:00:02                          

  Output-interface: GigabitEthernet0/0/1  NextHop: 115.1.1.2  MAC: 78-ac-c0-ac-93-7f 

  <--packets:1 bytes:40   -->packets:1 bytes:44                                

  4.0.2.1:10012-->4.0.2.11:139       //Packet from firewall (serving as the client) accessing the server

The packet that establishes the SSL VPN tunnel triggers the establishment of two identical sessions. One session is established during login, and one session is established when accessing service resources.

***ysis of the above session table gives the packet direction on FW, as shown in Figure 1-2.

Figure 1-2 Packet direction on FW

[Dr.WoW] [No.45] Configuring SSL VPN Security Policies-1314675-2 

From the above figure we learn that an Untrust Zone-->Local Zone security policy needs to be configured on FW, permitting the establishment of an SSL VPN tunnel between the remote user and FW; a Local Zone-->DMZ Zone security policy also needs to be configured, permitting FW to serve as a proxy for the remote user to access the server.

The security policy configuration approaches for the Web proxy/port forwarding functions are completely identical with that of file sharing. To summarize, the security policy match conditions that should be configured on the firewall for the above three functions are as shown in Table 1-1.

Table 1-1 Security zone match conditions

Service Direction

Source Security Zone

Destination Security Zone

Source Address

Destination Address

Application (protocol+destination port)

Remote user access to the server

Untrust

Local

ANY

4.1.64.12/32

TCP+443*

Local

DMZ

ANY**

4.0.2.11/24

TCP+139

TCP+445***

*: The port used by the device should be determined based upon actual circumstances.

**: For the USG6000 family of firewalls, although the source address displayed in the session table is the interface's private IP address, however, during actual configuration, the source address must be designation as 'ANY'. For the USG2000/5000 families of firewalls, the source address can be designated as the interface's private IP address during actual configuration.

***: The file sharing service is used as an example here; if this is the Web Proxy or port forwarding service, please determine this in accordance with actual circumstances.

 

2 Configuring a Security Policy in a Network Extension Scenario

The purpose of configuring a security policy in network extension scenarios is to achieve network layer interworking. Security policies also allow for permission control over remote user resource access.

In the below example, an SSL VPN tunnel is established between the remote user and the firewall, and the network extension service is used to access the company internal network's server. We'll assume that on the firewall, Interface GE0/0/1 is connected to the private network and belongs to the DMZ Zone, and that Interface GE0/0/2 is connected to the Internet and belongs to the Untrust Zone.

In network extension, whether or not the server and the virtual gateway address pool are in the same network segment affects the security zones traversed by service packets, and therefore the configuration of inter-zone security policies needs to be divided into the following two circumstances for discussion.

l   The server and the virtual gateway address pool are in the same network segment:

Figure 1-3 shows network organization when the server and the virtual gateway address pool are in the same network segment.

Figure 1-3 Network extension scenario with the server and the virtual gateway address pool in the same network segment

[Dr.WoW] [No.45] Configuring SSL VPN Security Policies-1314675-3 

The server and the virtual gateway address pool being in the same network segment means that a remote user who has obtained the private IP address is in the same network segment as the server. Of course, they are also in the same security zone―the DMZ.

After the remote user's access to the server through network extension is successful, we can verify this conclusion on FW's session table:

<FW> display firewall session table verbose                                

 Current Total Sessions : 3                                                    

  https  VPN:public --> public  ID: a48f3fc25ef7084f654bfcacd                  

  Zone: untrust--> local  TTL: 00:00:10  Left: 00:00:02                        

  Output-interface: InLoopBack0  NextHop: 127.0.0.1  MAC: 00-00-00-00-00-00    

  <--packets:10 bytes:2577   -->packets:9 bytes:804                             

  6.6.6.6:50369-->1.1.1.1:443                //packet establishing SSL VPN tunnel

                                                                                  

  icmp  VPN:public --> public  ID: a58f3fc25f2b05940054bfcb3f                  

  Zone: dmz--> dmz  TTL: 00:00:20  Left: 00:00:13    User: huibo               

  Output-interface: GigabitEthernet0/0/1  NextHop: 10.1.1.2  MAC: 00-22-a1-0a-eb-7d

  <--packets:3 bytes:180   -->packets:4 bytes:240                              

  10.1.1.10:1-->10.1.1.2:2048           //raw packet from remote user accessing the server

                                                                               

  https  VPN:public --> public  ID: a58f3fc25f1107f81954bfcace                 

  Zone: untrust--> local  TTL: 00:10:00  Left: 00:09:55                        

  Output-interface: InLoopBack0  NextHop: 127.0.0.1  MAC: 00-00-00-00-00-00    

  <--packets:34 bytes:4611   -->packets:44 bytes:14187                         

  6.6.6.6:58853-->1.1.1.1:443          // packet establishing SSL VPN tunnel

The packet establishing the SSL VPN tunnel triggers the establishment of two identical sessions: one is established during login, and one is established when initiating network extension.

Packet direction on the firewall can be obtained by ***yzing the above session table, as shown in Figure 1-4

Figure 1-4 Packet direction on the firewall when the server and the virtual gateway address pool are in the same network segment

[Dr.WoW] [No.45] Configuring SSL VPN Security Policies-1314675-4 

From the above figure we can learn that an Untrust-->Local security policy needs to be configured to permit the establishment of an SSL VPN tunnel between the remote user and the firewall; a DMZ-->DMZ security policy also needs to be configured to guarantee that service packets can pass (USG6000 series firewalls' default settings do not permit packet movement within security zones, so this security policy needs to be configured. USG2000/5000 series firewalls do not have this restriction.)

In summary, the security policy match conditions that should be configured on the firewall are shown in Table 1-2.

Table 1-2 Security policy match conditions

Service direction

Source security zone

Destination security zone

Source address

Destination address

Application (protocol +destination port)

Remote user access to the server

Untrust

Local

ANY

1.1.1.1/32

Reliable transport mode

TCP+443

Fast transport mode

TCP+UDP+443*

DMZ

DMZ

10.1.1.0/24

(this is the virtual network card address pool's corresponding network segment)**

10.1.1.2/32

***

*: The port used by devices should be determined based on actual circumstances. The above is an example of the remote user using the reliable transport mode to establish an SSL VPN tunnel. When a tunnel is established using the fast transport mode, a UDP session will still be generated between the Untrust-->Local zones, and this application needs to be configured in the security policy at this time.

**: In addition to the source address, the USG6000 series of firewalls also support user-based security policies, and can use a remote user's user name as a match condition to configure the security policy. As compared to the source address, using the user name as the match condition increases visibility and precision.

***: The application here is related to the specific service type, and can be configured according to actual circumstances. For example, TCP, UDP, ICMP, etc.

 

l   The server and the virtual gateway's address pool are not in the same network segment:

Figure 1-5 shows a network in which the server and the virtual gateway address pool are not in the same network segment.

Figure 1-5 Network extension scenario in which the server and the virtual gateway address pool are not in the same network segment

[Dr.WoW] [No.45] Configuring SSL VPN Security Policies-1314675-5 

The server and the virtual gateway address pool not being in the same network segment means that a remote user who has obtained the private network IP address is in a different network segment from the server, and of course the two are also located in different security zones. With this being the case, which security zone exactly does the user belong to?

If there is not a route to the 192.168.1.0/24 network segment on the virtual gateway, it is impossible for the virtual gateway to confirm the source security zone the remote user belongs to, and it will discard the packets the remote user sends. In order to resolve this problem, we need to manually configure a route that has the virtual gateway address pool (network segment 192.168.1.0/24) as its destination address; the outbound interface can be unilaterally chosen by the administrator. This is to say that what this packet's source security zone is at this time depends upon which outbound interface is used for this route we are configuring. We introduced content pertaining to this in "8.5.4 Configuring Network Extension."

We normally believe that since this packet comes from the Internet, it comes from the Untrust Zone. Therefore, when we configure routes, we configure the route's outbound interface as the public interface GE0/0/2 that is linked with the Internet. Using this route, it can be confirmed that the data flow from a remote user accessing the server constitutes data traveling from Untrust to the DMZ.

After the remote user successfully accesses the server through network extension, we can verify this conclusion using FW's session table.

<FW> display firewall session table verbose                                

 Current Total Sessions : 3                                                    

                    

  https  VPN:public --> public  ID: a58f3fe3a31502f49354bfcccf                 

  Zone: untrust--> local  TTL: 00:10:00  Left: 00:10:00                        

  Output-interface: InLoopBack0  NextHop: 127.0.0.1  MAC: 00-00-00-00-00-00    

  <--packets:36 bytes:4989   -->packets:54 bytes:20751                         

  6.6.6.6:51668-->1.1.1.1:443             //packet establishing SSL VPN tunnel

                                                                               

  icmp  VPN:public --> public  ID: a58f3fe3a36302f8d854bfcd3d                  

  Zone: untrust--> dmz  TTL: 00:00:20  Left: 00:00:20    User: huibo           

  Output-interface: GigabitEthernet0/0/1  NextHop: 10.1.1.2  MAC: 00-22-a1-0a-eb-7d

  <--packets:3 bytes:180   -->packets:3 bytes:180                              

  192.168.1.1:1-->10.1.1.2:2048        //remote packet from remote user accessing server

                                                                               

  https  VPN:public --> public  ID: a58f3fe3a2fb03e68154bfccce                 

  Zone: untrust--> local  TTL: 00:10:00  Left: 00:08:08                        

  Output-interface: InLoopBack0  NextHop: 127.0.0.1  MAC: 00-00-00-00-00-00    

  <--packets:6 bytes:2417   -->packets:7 bytes:724                             

  6.6.6.6:51255-->1.1.1.1:443             //packet establishing an SSL VPN tunnel.

***yzing the above session table gives the packet direction on the firewall, as shown in Figure 1-6.

Figure 1-6 Packet direction on the firewall when the server and the virtual gateway address pool are not in the same network segment

[Dr.WoW] [No.45] Configuring SSL VPN Security Policies-1314675-6 

As shown in the above diagram, an Untrust-->Local security policy needs to be configured to permit the establishment of an SSL VPN tunnel between the remote user and the firewall; an Untrust-->DMZ security policy needs to be configured to guarantee that service packets can pass. 

To summarize, the security policy match conditions that should be configured on the firewall are as shown in Table 1-3.

Table 1-3 Security policy configuration conditions

Service direction

Source security zone

Destination security zone

Source address

Destination address

Application (protocol+destination port)

Remote user access to the server

Untrust

Local

ANY

1.1.1.1/32

Reliable transport mode

TCP+443

Fast transport mode:

TCP+UDP+443*

Untrust

DMZ

192.168.1.0/24 (this is the virtual gateway card's address pool's corresponding network segment)**

10.1.1.2/32

***

*: The port used by devices should be determined based on actual circumstances. The above is an example of the remote user using the reliable transport mode to establish an SSL VPN tunnel. When a tunnel is established using the fast transport mode, a UDP session will still be generated between the Untrust-->Local zones, and this application needs to be configured in the security policy at this time.

**: In addition to the source address, the USG6000 series of firewalls also support user-based security policies, and can use a remote user's user name as a match condition to configure the security policy. As compared to the source address, using the user name as the match condition increases visibility and precision.

***: The application here is related to the specific service type, and can be configured according to actual circumstances. For example, TCP, UDP, ICMP, etc.

 

 

 

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

  • x
  • convention:

user_2790689
Created Oct 29, 2015 03:18:02 Helpful(0) Helpful(0)

Thank you.
  • x
  • convention:

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