Unable to Connect to or Ping a Firewall Interface

Issue

When attempting to access or connect to a firewall interface IP address for a service or when trying to ping the interface the communication fails.  This could be to manage the device over HTTPS or SSH, to connect to the GlobalProtect Portal or to the NetConnect web portal, or simply attempting to ping the interface.

Resolution

• Make sure the interface has the appropriate management profile configured for it that enables the services needed and that permits the IP addresses from which the connection is being made.
  • If the management profile is suspect, then run the following counter command and watch for counter increments: > show counter global name flow_host_service_deny
• Verify that no security policy is blocking the traffic to the interface by checking the traffic logs. Filter the destination address to be the IP address of the firewall interface. Typically, a security policy won't block the connectivity, but it is possible.
  • If the interface being reached is different than the interface which the initiating packet ingresses into the firewall, and those two interfaces are in different zones, then that would be considered an inter zone session and a security policy must be present which allows the session.
  • If the interface being reached is the same as the interface which the initiating packet ingresses into the firewall, then that would be considered an intra zone session and a security policy is not required as intra zone sessions are allowed by default. However, the presence of an explicitly defined deny any to any zone security policy will override the default allow. It would be necessary then to have a more explicit policy that allowed the initiating session to the firewall interface.

Note: If no logs are observed for the interface session, remember that when default actions are taken on inter zone sessions or intra zone sessions there is no traffic log generated for that deny or allow (respectively).

• If the problem is still not resolved another possible issue is the presence of a source NAT which translates the source address of the initiating packet to the address of the interface that is being reached. This causes the firewall to drop the packet early on in it's processing of the packet because after the translation the packet looks like a LAND attack where both source and destination addresses are the same.
  • This is often the behavior seen when testing connectivity to the GlobalProtect Portal when it is configured on the external interface and the testing computer is on the internal network since the initiating packet will be translated to the external interface by the source NAT used to access the external zone.
  • No traffic logs will be seen in this case as this mechanism kicks in before the logging process.
  • Issue the following command to check for increments to see if this is the problem: > show counter global name flow_policy_nat_land
  • To resolve the problem, clone the offending NAT policy and change the Source Translation to "none" and the Destination Address to the IP address of the concerned interface, and finally place that policy directly above the offending NAT policy.  This prevents the translation from occurring for those hosts only when the destination is the interface.
• Another problem that can be caused by a NAT policy is if a destination NAT is configured to translate packets that have a destination address as the concerned interface address into the address of a server.  Typically, this destination NAT will involve the pubic IP address of the external interface,  There are two different NAT configurations that may be encountered for this problem.
  • If the destination NAT is for all services, then any packet with a destination address as the interface that hits that NAT policy will be translated even if the intention is to reach the interface and not the remote host. The following could resolve this problem:
    • If the server is only needed for specific services or ports which are different then the port needed to reach the firewall interface, then narrow the NAT policy so that only necessary services are translated and forwarded to the server.
  • If particular services are specified for that destination NAT then only packets which match a destination port with those services will be translated to the host and if port 443 is among the translated services for example, then there will be no access to port 443 on the firewall interface for packets which do match the destination NAT policy.  The following could resolve this problem:
  • • Add another address to the firewall interface if there is a free address available.  If adding an address in the same subnet, then the subnet mask will need to be a /32.
    • The firewall interface address must be changed or the server address must be changed.
    • If neither of the options above are desired actions, then the problem is likely due to not having enough public addresses for the services being offered.  A more complicated workaround may be possible, but it may be necessary to acquire additional public addresses.
• If none of the above resolve the problem, then it is definitely worth checking routes on the networks between the initiating computer and the firewall interface.  Check whether or not other computers can access the firewall interface.  If necessary, do a packet capture on the firewall to see if the initiating packet is even reaching the firewall.

Example Source NAT that would prevent hosts in the trust zone from accessing the external interface IP address:

Example Destination NAT that would prevent any access from the Internet to the external interface IP address:

Note: The resolutions do not apply to the management interface of the firewall.

owner: astanton