Considerations for setting up system communications

Firewalls and Layer 2 Firewalls do not automatically allow communications of other system components that pass through the engine. Make sure that all necessary traffic is allowed in the engine's policy.

The predefined Firewall Template Policy and Layer 2 Firewall Template Policy allow most types of system communications between the engine and the components it interacts with. You must create rules to allow any other communications through Firewalls or Layer 2 Firewalls.

System communications through a NAT device

If NAT is applied between two SMC components, you must define the translated IP address as a contact address. In NATed communications, the contact address is contacted instead of the component’s real IP address. A single component can have several contact addresses.

Location elements define when a contact address is used and which of the defined contact addresses is used. When NAT is applied between two communicating SMC components, you must separate them into different locations. Components that are in the same location use the primary IP address when communicating with each other and ignore all contact addresses. When components contact a component that belongs to a different location, they use the defined contact address.

For example, when a Management Server contacts an engine node through NAT, the Management Server uses the NATed contact address, not the engine’s real IP address. The NAT device between the components translates the NATed address to the engine’s real IP address as usual.

You can define a default contact address for contacting a component in the Properties dialog box of the element. When components that belong to another location contact the element and the element has no contact address defined for its location, the element’s default contact address is used.

If you do not select a location for an element that has the location option, the element’s location is set to Not Specified. When SMC and NGFW components contact components for which the location is not specified, they use the element’s default contact address. If you want components to use the primary IP address when communicating with each other, the elements must belong to the same location, or you must define a location-specific exception for the elements.

Example of using contact addresses and locations

In this example scenario, a Management Server and a Log Server manage SMC components both at a company’s headquarters and at three branch offices.

The SMC servers and the Central Firewall are at the “Headquarters” location.
The Remote Firewalls are all at the “Branch Office” location.

In this scenario, contact addresses are typically needed as follows:

The Firewall at the headquarters or an external router can provide the SMC servers external IP addresses on the Internet. The components at the branch offices contact the servers through the Internet. The external addresses of the SMC servers must be defined as contact addresses for the “Branch Office” location.
The Branch Office Firewall or an external router can provide external addresses for the SMC components at the branch office. The external IP addresses of the engines must be defined as contact addresses for the “Headquarters” location so that the Management Server can contact the components.
Alternatively, the external address of each component can be defined as a Default contact address without adding a specific entry for “Headquarters” or “Branch Office”. The Default contact address is used when a component does not have a specific contact address definition for the contacting component’s location. The components must still be divided into separate locations for the contact address to be used.

If there are Management Clients used at any of the branch offices, each administrator must also select “Branch Office” as their location in the Management Client. Selecting the Management Client location allows administrators to view logs from a remote Log Server that is behind a NAT device.