The customer‘s eSpace client login abnormally from internet when USG6350 as the gateway case

Publication Date:  2014-12-30 Views:  515 Downloads:  0
Issue Description
The customers use eSpace mobile client App to login internal server with VPN security gateway setting, sometimes, eSpace client can’t login from internet. 

The network topology is shown:
Handling Process
1.  When the issue happens, we do the SSL VPN access test (https://xx.yy.131.131), and capture packets on the uplink interface of SVN device and the client at the same time. After we analyzed all captured packets, we find that at the client side, after TCP shake hands successfully, client sends ‘client hello’, at the same time, the SVN device also sends ‘server hello’ packet, but they don’t receive the packets which sends by each other, as per this information, we consider that the SSL connect failed is caused by middle device block these packets. According to the customer network topology, we consider maybe the issue is caused by firewall USG6650 which plays the role of gateway.

2.  And then we analyze the firewall USG6650 configuration, we find that the security gateway global IP address xx.yy.131.131 has been mapped to 172.20.0.2 and only open TCP port 443, as following:

nat server "SVN https" protocol tcp global xx.yy.131.131 443 inside 172.20.0.2 443

3.  When the issue happens, we analyze the firewall session related to xx.yy.131.131, we see the session TTL is 10 minutes, this indicates TCP shake hands successfully, but from the packets count, there aren’t follow-up packets. 

https  VPN:public --> public  ID: a58f6c2c2a990917915482e11b
Zone: untrust--> trust  TTL: 00:10:00  Left: 00:09:55
Output-interface: Eth-Trunk1  NextHop: 10.163.30.2  MAC: XX-YY-3d-d1-43-ZZ
<--packets:1 bytes:44   -->packets:2 bytes:92
xx.yy.106.37:2340-->xx.yy.131.131:443[172.20.0.2:443]


4.  Analyze the client captured packets related with xx.yy.131.131, from the captured packets, we find that TCP shake hands successfully, and client sends the follow-up SSL ‘client hello’, but always retransmit this packet, this information indicates the server side doesn’t receive this packet.

5.  To compare the captured packets and firewall session, we can see the packets of TCP shake hands are counted in the session (<--packets:1 bytes:44   -->packets:2 bytes:92, one direction SYN,ACK, other direction (SYN+ACK)), but the SSL ‘client hello’ doesn’t be counted, this indicates maybe SSL packets don't go through firewall.

6.  When eSpace login from internet meets problem, but login from internal network is normal. The difference between two operations is using different security policy between different zones on the firewall. When from internet match ‘untrust->trust’, but when from internal is match ‘trust->trust’.

According to firewall configuration, the security policy between ‘untrust->trust’ has been configured some application policies, if packets match these policies, firewall will permit them, if not, firewall will drop these packets (there isn’t ‘default action permit’ in the current configuration). But between ‘trust->trust’ has been configured as all packets are permitted.

From the configuration between ‘untrust->trust’, the policy has been configured HTTPS application. Normally, HTTPS packets will be permitted, but why the packets are dropped in truth now?

security-policy 
……
rule name 2
  policy logging
  session logging

  source-zone untrust
  destination-zone trust

  application app BT
  application app HTTP
  application app SIP
  application app RDP
  application app SNMP
  application app DNS

  application app HTTPS
  application app HTTP_Proxy
  application app NetBios_Name_Service
  application app General_TCP
  session traffic statistic logging enable
  profile av default
  profile data-filter default
  profile file-block default
  profile ips default
  profile url-filter default
  action permit
……
rule name trust_to_trust
  policy logging

  source-zone trust
  destination-zone trust
  action permit


7.  The principle of application identified on firewall is when configure application in security policy, if match the zone parameters, these packets will be sent to NGE module process, different services need the quantity of packets are different. Meanwhile, if the service is multilayer protocol, the NGE will identify the protocols in every layer.

For HTTPS application, SSL protocol is between HTTP and TCP, in other words, SSL protocol is the bearer protocol of HTTPS. When firewall identifies the HTTPS application, according to different traffic, maybe need several packets to confirm the protocol is HTTPS, before HTTPS protocol isn’t confirmed, it will not be used for the security policy. When bearer protocol SSL is identified firstly, and also need more packets to identified HTTPS protocol, at this situation, because of the current security policy only include ‘application app HTTPS’, doesn’t include the bearer protocol ‘application app SSL’, the follow-up packets can’t be processed and forwarded, and then firewall block the HTTPS packets, further to cause eSpace client App can’t login from internet.

Because of application identified depends on service traffic, if HTTPS protocol is identified by 1 packet, at this situation, the firewall will permit packets. This is the reason of eSpace sometimes can login, sometimes can’t login. But in which situations HTTPS protocol can be identified by 1 packet depends on the behavior of the application and network environment (IP fragment, TCP sections and so on).
Root Cause
In conclusion, the root cause of the eSpace mobile application login abnormal from internet is between firewall zones ‘untrust->trust’, only permit the application HTTPS (application app HTTPS), but doesn’t permit SSL protocol which is the bearer protocol of HTTPS (application app SSL). Because of this, when the protocol is identified as SSL but doesn’t be confirmed as HTTPS, the follow-up packets will be dropped by firewall default security policy.  
Solution
The solution is to configure the SSL application in security policy which has been configured HTTPS between firewall zones ‘untrust->trust’. To make sure firewall will permit all the SSL protocol packets when HTTPS isn’t identified. The configuration as following:

security-policy
……
rule name 2
  policy logging
  session logging
  source-zone untrust
  destination-zone trust
  application app BT
  application app HTTP
  application app SIP
  application app RDP
  application app SNMP
  application app DNS

  application app SSL
  application app HTTPS

  application app HTTP_Proxy
  application app NetBios_Name_Service
  application app General_TCP
  session traffic statistic logging enable
  profile av default
  profile data-filter default
  profile file-block default
  profile ips default
  profile url-filter default
  action permit

END