Understanding Server Map

Overview

Generally, strict security policies permit only connections that are initiated from intranets. In practice, for example, in FTP port mode, the control connection is initiated from the client, and the data connection is initiated from the server. Therefore, if connections can be initiated only from intranets, the FTP connection cannot be established.

To resolve this issue, the FW uses server map entries for saving mappings. The mappings can be data connections negotiated by the control channel or address mappings in NAT, so that connections can be initiated from the Internet.

After a server map entry is generated, if a packet matches the server map entry, the device will forward the packet and create a session to forward subsequent packets based on the session.

Server Map Entries Generated When the FW Forwards the Traffic of Multi-Channel Protocols, such as FTP and RTSP

The FW generates server map entries when forwarding the traffic of multi-channel protocols, such as FTP and RTSP.

The data connection of a multi-channel protocol is negotiated on the control connection. Therefore, source and destination ports of the data connection are dynamically negotiated.

• If application identification or IPS detection is required for service traffic, server map entries are automatically generated after SA service identification is performed on control channel packets. SA service identification is no longer performed on data channel packets. Instead, the SA identification result of the control channel packets applies. The corresponding server map entries are as follows: (The destination port in the server map is the data channel port number negotiated through the control channel.)

  Type: SA,  ANY -> 10.40.0.10:2165,  Zone:---
  Protocol: tcp(Appro: FTP),  Left-Time:00:02:58
  Vpn: public -> public

• If ASPF is enabled on the FW, the FW reads the negotiation messages on the control channel and dynamically creates a server map entry. This entry is based on the address information in the payload of the negotiation messages. The server map entry now contains the negotiated data connection information.

  For example, in FTP port mode, the FW randomly selects a port (2165 in this example) for the data channel on the FTP client and sends the port number to the FTP server through the control channel. Then the FTP server initiates a data connection to the port.

  The corresponding server map entries are as follows:

  Type: ASPF,  10.40.0.5 -> 10.40.0.10:2165,  Zone:---
  Protocol: tcp(Appro: ftp-data),  Left-Time:00:04:47
  Vpn: public -> public

• If not only application identification or IPS detection but also ASPF is configured, the following server map entries are generated:

  Type: SA ASPF,  10.40.0.5 -> 10.40.0.10:2165,  Zone:---
  Protocol: tcp(Appro: ftp-data),  Left-Time:00:04:47
  Vpn: public -> public

tcp(Appro: ftp-data) indicates that the server map entry is used to forward FTP traffic on the data channel. 10.40.0.5 is the source IP address, that is, the IP address of the FTP server that initiates the connection. 10.40.0.10 is the destination IP address, that is, the IP address of the FTP client.

If strict security policies are used, the security policy for permitting the packets of port 2165 is not configured, and therefore no server map entry exists. As a result, the connection is blocked. If ASPF is enabled, the FW automatically generates a server map entry for the negotiated connection and permits subsequent packets that match the server map entry.

3-Tuple Server Map Entries Generated When the FW Forwards the Traffic of STUN Protocols

The FW generates 3-tuple server map entries when forwarding the traffic of STUN protocols, such MSN.

After an MSN user logs in, the user IP address and port are determined, but those of another party that may initiate a connection to the user remain unknown. If you configure ASPF, the FW records the user IP address and port and generates a dynamic server map entry when the MSN user is connected to the server. The server map entry contains only the 3-tuple information; that is, the IP address, port, and protocol of only one communication party. Other users can then use the known IP address and port to communicate with this user. If traffic keeps arriving, the dynamic STUN server map entries do not age. If no traffic is forwarded, the server map entries begin to age.

For example:

Type: STUN : any -> 10.40.0.10:4967,  Zone: ---
protocol:udp(Appro: qq-derived),  Left-Time:00:04:47,  Pool: ---
Vpn: public --> public

Type: STUN reverse : 10.40.0.10:4967 -> any,  Zone: ---
protocol:udp(Appro: qq-derived),  Left-Time:00:04:47,  Pool: ---
Vpn: public --> public

In this example, the source IP address is any; that is, any user can initiate a connection to port 4967 at 10.40.0.10.

Static Server Map Entries Generated When the NAT Policy Server Mapping Is Configured

After the NAT policy server mapping is configured, Internet users can initiate access requests to the intranet server. The IP addresses and ports of the users are unknown, but the internal IP address and port of the intranet server are known.

Therefore, the FW automatically generates server map entries to maintain the mappings between the Global and Inside IP addresses. Then the FW can translate IP addresses and forward packets according to the mappings.

The static server map entries are generated for each NAT policy server mapping. If you delete the NAT policy server mapping configuration, the server map entries are also deleted.

The following screenshot shows server map entries generated when the NAT policy server mapping is configured:

Type: Nat Server,  ANY -> 10.10.1.100:21[10.1.1.2:21],  Zone:---,  protocol:tcp
Vpn: public --> public

Type: Nat Server Reverse,  10.1.1.2[10.10.1.100] -> ANY,  Zone:--- ,  protocol:tcp
Vpn: public --> public,  counter: 1 

• Nat Server indicates the server map entry for forward traffic (initiated from the clients on the Internet to the intranet server).

• Nat Server Reverse indicates the server map entry for return traffic (initiated from the intranet server to the clients on the Internet).

• Protocol indicates the protocol that is specified when you configure NAT policy server mapping.

• 10.10.1.100 indicates the IP address of NAT policy server mapping.

• 10.1.1.2 indicates the inside IP address of the NAT policy server mapping; that is the pre-NAT internal IP address.

Dynamic Server Map Entries Generated When NAT No-PAT Is Configured

If you configure NAT and specify the No-PAT parameter, the FW translates only the IP addresses but not the port numbers. In this case, all the ports at internal IP addresses are translated to ports at external IP addresses, and Internet users can initiate connections to any ports on the intranet.

After NAT No-PAT is configured, the FW creates server map entries for the data flows in order to maintain the mappings between the internal and external IP addresses. Then the FW translates the IP addresses and forwards the packets according to the mappings.

For example, the server map entries generated when the NAT No-PAT is configured are as follows:

 Type: No-Pat,  10.1.1.100[10.10.1.1] -> ANY,  Zone:--- 
 Protocol: ANY, TTL:360, Left-Time:353,  Pool: 3, Section: 0
 Vpn: public

 Type: No-Pat Reverse, ANY -> 10.10.1.1[10.1.1.100],  Zone:--- 
 Protocol: ANY, TTL:---, Left-Time:---,  Pool: 3, Section: 0
 Vpn: public

• No-Pat indicates the server map entry for forward traffic (initiated from an internal IP address).

• No-Pat Reverse indicates the server map entry for the return traffic (initiated from the Internet to the intranet).

• 10.1.1.100 indicates the pre-NAT internal IP address.

• 10.10.1.1 indicates the post-NAT external IP address.

Dynamic Server Map Entries Generated When Full-Cone 3-Tuple NAT Is Configured

After the full-cone 3-tuple NAT is configured, the FW creates server map entries for the data flows with actual traffic.

• If the mode Full-cone global command is executed to configure global 3-tuple NAT, the generated server map entries are as follows:

  Type: FullCone Dst,  ANY -> 192.168.20.105:6144[10.10.10.2:44023],  Zone: ---
   Protocol: icmp(Appro: ---),  TTL: 60,  Left-Time: 47,  Pool: 0, Section: 0
   Vpn: public -> public,  Hotversion: 1
  Type: FullCone Src,  10.10.10.2:44023[192.168.20.105:6144] -> ANY,  Zone:---
   Protocol: icmp(Appro: ---),  TTL: 60,  Left-Time: 10,  Pool: 0, Section: 0
   Vpn: public -> public,  Hotversion: 1

• If the mode Full-cone local command is executed to configure local 3-tuple NAT, the generated server map entries are as follows:

  Type: FullCone Src,  10.10.10.2:44023[192.168.20.105:6144] -> ANY,  Zone:trust
   Protocol: icmp(Appro: ---),  TTL: 60,  Left-Time: 10,  Pool: 0, Section: 0
   Vpn: public -> public,  Hotversion: 1
  
  Type: FullCone Dst,  ANY -> 192.168.20.105:6144[10.10.10.2:44023],  Zone: trust
   Protocol: icmp(Appro: ---),  TTL: 60,  Left-Time: 47,  Pool: 0, Section: 0
   Vpn: public -> public,  Hotversion: 1

Zone indicates the security zone. If global 3-tuple NAT is configured, the server map entries do not contain any security zone parameter and are not subject to interzone relationship restriction. If local 3-tuple NAT is configured, the server map entries contain security zone parameters and are restricted by interzone relationships.

Dynamic Server Map Entries Generated When PCP Is Configured

After receiving the PCP request packets from the CPE, the FW parses the packets, allocates the public IP addresses and ports from the pre-configured NAT address pool to access users, and generates PCP mappings.

• If the FW receives requests packets in PEER mode from the CPE, the generated server map entries are as follows:

  Type: PEER,    Protocol: UDP, Zone: ---, Vpn: public
   192.168.0.10:17192[1.1.1.3:9000] -> 2.2.2.10:1280
   TTL: 1800, Left: 1800, Pool: 30, Section: 1
   Mapping Nonce: 0x353137383539353136000000

• If the FW receives requests packets in MAP mode from the CPE, the generated server map entries are as follows:

  Type: MAP IN,  Protocol: TCP, Zone: ---, Vpn: public
   ANY -> 1.1.1.3:2048[192.168.0.10:5791]
   TTL: 120, Left: 120, Pool: 10000, Section: 0
   Mapping Nonce: 0x000000000000000032142158, Filter(s): 0
  
   Type: MAP OUT, Protocol: TCP, Zone: ---, Vpn: public
   192.168.0.10:5791[1.1.1.3:2048] -> ANY
   TTL: 120, Left: 120, Pool: 10000, Section: 0
   Mapping Nonce: 0x000000000000000032142158, Filter(s): 0
  

• PEER: In this mode, private network users can access the Internet, but Internet users cannot initiate access to private network users. Therefore, the PEER mode is not applicable to P2P services.

• MAP IN: In this mode, Internet users can initiate access to private network users using the MAP IN entries. Therefore, the MAP mode is applicable to P2P services.

Static Server Map Entries Generated When SLB Is Configured

The SLB function uses the server map and the session table to complete mapping between the virtual server and real server. After SLB is configured, the FW generates a static SLB server map, which ages out immediately upon the disabling of SLB.

The typical SLB-type static server map is as follows:

 Type: SLB,  ANY -> 1.1.1.10:8080[grp1/1],  Zone:---,  protocol:tcp
 Vpn: public -> public  

In this example, ANY indicates that the FW has no limit on the devices accessing the virtual server. grp1/1 indicates the name and ID of the real server group associated with the virtual server. The FW does not support cross-virtual system access to the virtual server.

Dynamic Server Map Entries Generated When NAT Server Is Configured in DS-Lite Scenarios

If Internet users need to access servers on private networks, configure NAT Server for DS-Lite. Then corresponding server map entries will be generated.

Type: DS-Lite Nat Server, ANY -> 1.1.2.12:21[192.168.1.2:21], Zone:---
 Protocol: tcp, To CPE: 3000::1, Tunnel Id: 1, Left-Time:--- 

Type: DS-Lite Nat Server Reverse,  192.168.1.2[1.1.2.12] -> ANY, Zone:---       
 Protocol: tcp, From CPE: 3000::1, Tunnel Id: 1, Left-Time:---, counter: 3

If nat-dslite server is followed by parameter no-reverse, only forward server map entries are generated.

Static Server Map Entries Generated When Static NAT64 Is Configured

If IPv6 networks need to initiate access to IPv4 networks, configure static NAT64. The corresponding static server map entries will be generated.

Type: NAT64 Static, ANY -> 11.2.0.100[1800::23], Zone:--- 
Protocol: ANY, TTL:---, Left-Time:---, Pool:---, Section:--- 
Vpn: public -> public 

Type: NAT64 Static, 1800::23[11.2.0.100] -> ANY, Zone:--- 
Protocol: ANY, TTL:---, Left-Time:---, Pool:---, Section:--- 
Vpn: public -> public 

Aging of Server Map Entries

Server map entries occupy device resources. The FW provides an aging mechanism to clear the server map entries that meet the specified aging conditions.

Table 1 lists the aging mechanisms for the server map entries.

Relationship Between the Server Map Table and Security Policies

The server map entry generated by the ASPF/ALG function has a higher priority than the security policy. After a packet matches an ASPF/ALG server map entry, security policy check is no longer required.

As for the server map table generated by the NAT Full-cone, NAT64, or PCP function, after the firewall endpoint-independent filter enable command is run to enable the endpoint-independent filter, packets are matched against the server map table first, and address translation is performed based on the server map table, no longer requiring security policy check. If the endpoint-independent filter is disabled, security policy check is still performed on packets matching the server map table.

For server map entries of other types, security policy check is required on packets matching server map entries.

Position of the Server Map in the Forwarding

After a packet that does not match any session entry passes the security check, the FW looks up the server map before searching for a route for the packet. The FW looks up the server map for two purposes:

• To verify the connection status of the packet

  The packet that does not match any session entry may belong to a special service that requires a server map. By looking up the server map, the FW determines whether the packet belongs to an existing connection. If the packet neither matches any session entry nor belongs to any existing special service, the FW discards the packet based on strict security policies.

• To translate certain packet information based on the server map

  In addition to key packet information, the server map records the processing measures on the packet. For a packet that matches a server map entry, the FW translates the packet based on the entry. For example, when NAT policy server mapping is configured, the FW translates the destination external IP address of the packet destined for the intranet into an internal IP address.

The server map entry does not record the information about the next hop of the packet. Therefore, the server map entry is used to check only the first packet. After the packet passes the inspection, the FW generates a session entry for the forwarding of subsequent packets. In other words, the server map is used only for establishing a new connection. The packets are forwarded according to the session table after the connection is established.

The following uses FTP in port mode as an example. Host A at 192.168.1.1 initiates an FTP connection from port 20000 to port 21 on server B at 10.11.1.1. The connection request is permitted based on the security policies on the FW.

1. After the packet for initiating a connection is permitted, the FW creates a session entry, and the control channel is established.

   Type	Source IP Address	Source Port	Destination IP Address	Destination Port	Protocol
   Session entry	192.168.1.1	20000	10.11.1.1	21	FTP

2. After the negotiation of the control channel, host A randomly selects a port (for example, port 2165) for the data channel, and then sends the port number to the FTP server through the control channel. After receiving the packet, the FW establishes a server map entry accordingly.

   Type	Source IP Address	Destination IP Address	Destination Port	Protocol
   Server map entry	10.11.1.1	192.168.1.1	2165	FTP-Data

3. After receiving the negotiation packet from host A, server B initiates a connection from port 20 to port 2165 at 192.168.1.1. The connection does not match any session entry in the session table. If the default interzone security policy is deny, the packet may be discarded. Therefore, the FW checks the server map to determine whether the packet belongs to a special service.

   Since the source IP address, destination IP address, destination port, and protocol of the packet are the same as those in the server map, the FW allows this packet through. Moreover, the 5-tuple of the new data channel is determined, and the FW creates a session entry. Then the data channel between the communication parties is established.

   Type	Source IP Address	Source Port	Destination IP Address	Destination Port	Protocol
   Session entry	10.11.1.1	20	192.168.1.1	2165	FTP-Data

4. Subsequent packets in the data channel can match this session entry and be forwarded without matching any server map entry. The server map entry is not matched by any packet and will be deleted after the aging timer expires to ensure network security.

Server Map Entries Matching

When there are multiple server map entries, the device selects the most accurate server map entry. For example, the following two NAT server mapping entries exist on the device:

Type: Nat Server, ANY -> 10.3.3.3[10.4.4.4], Zone:---, protocol:--- Vpn: public -> public 
Type: Nat Server, ANY -> 10.3.3.3:80[10.5.5.5:80], Zone:---, protocol:tcp Vpn: public -> public

Traffic to port 80 of 10.3.3.3 matches the second entry because the second entry matches the traffic more accurately.

In addition, different types of server map entries have the same precision due to configuration reasons. In this case, the device randomly matches the server map entries.