Network objects represent hosts on a network and can include subnets, single hosts, or groups of both. Once defined, a network object may be used throughout the Exinda appliance for monitoring, for identifying which traffic should be processed in the policy engine, and to configure other objects, such as applications, adaptive response rules, application performance score objects, and application performance metric objects. Network objects are also used to determine which traffic is considered inbound to your network and which traffic is outbound.
The location of a network object determines the direction of traffic. If one end of the conversation is defined in an external network object and the other is defined in an internal network object, then traffic from an external network object to an internal network object is considered inbound traffic. Conversely, traffic from an internal network object to an external network object is considered outbound traffic.
You can also indicate whether you want to report on the traffic relative to the network object, that is chart the traffic in and out of a given network object. By checking the Subnet Report checkbox, the data for the network object will be shown on the subnet monitor page. This setting only affects the display of the data. The data will be collected regardless of this setting.
Some network objects are automatically created by the appliance: ALL, private net and local
Where to configure it
Go to Configuration > Objects > Network Object > Network Objects.
To create a new network object
Select the location of the network object - internal, external, or inherit.
Packets are matched to a network object, and the closest subnet within that network object determines the location. See examples below.
Internal — All subnets and hosts defined by the network object will be considered on the LAN side of the appliance.
Inherit — The locations of the subnets and hosts defined by the network object is determined or inherited by closest match to other network objects.
|
Note When creating network objects that have location set to "inherit", you can use the CLI command show network-object <name> to show the location. |
|---|
Specify the network IP address and netmask length of the subnet. IPv4 and IPv6 addresses are accepted.
Although only four lines for IP addresses are displayed for a new object, add more IP addresses by saving the network object and click Edit to be presented with an extra 4 lines.
To save the changes to the configuration file, in the status bar click the Unsaved changes menu and select Save configuration changes.
Examples of network object definitions
|
E X A M P L E – Network object defining two internal proxy servers Create a network object that defines two internal proxy servers, 192.168.1.10 and 192.168.1.11: Name: Web Proxies |
|
E X A M P L E – Head office defining a network object for a remote branch Create a network object that defines the Head Office location, that has a subnet 10.0.100.0/24, where this Exinda appliance is NOT deployed: Name: Head Office |
|
E X A M P L E – Network object defining an internal IPv6 server Create a network object that defines the internal IPv6 server at 2001:db8::1234:5678 Name: FileServer6 |
|
E X A M P L E – Network object with inherited location Define three network objects as follows: Name: HQ Subnets: 10.0.0.0/8 Location: External Subnets are matched by decreasing netmask length. The Server-1 network object 10.0.1.200 will be internal, as it most closely matches the Office-A Network Object which is internal. Since the Server-1 Network Object contains a single subnet that can be matched to Office-A, its location is shown as internal. |
What about internal-to-internal or external-to-external traffic?
When the Ignore Internal-to-Internal option is set on the Monitoring configuration page, all traffic between network objects marked as internal is ignored and passed through the Exinda appliance unaffected. See Monitoring Configuration.
How do I know whether a network object with location 'inherit' resolved to internal or external location?
You can use the CLI command to see what location the network object resolved to:
show network-object <name>
Creating Network Objects based on FQDN?
It is possible to configure network objects using fully-qualified-domain-names instead of IP addresses. Should it later become necessary to change network settings on application servers, the Exinda appliance can then automatically detect the change through DNS.
To configure a network object based on a fully qualified domain name, use the following commands:
>en
#conf t
(config) # network-object <NAME> fqdn <fully qualified domain name>
An Exinda appliance must be configured with a DNS server if it is to perform name resolution using FQDN. Each record retrieved has a life cycle equal to the TTL (Time to live) defined for such a record. When the TTL is exceeded, Exinda automatically refreshes the record to verify that the IP address has not changed. When appliance reboots occur, or changes to DNS configuration, interface configurations, or link states on any interface, this causes an automatic refresh of the network object. Should you need to perform a refresh, you can use the following command:
(config) # network-object <NAME> refresh
When the TTL is lower than 5 minutes, Exinda waits the full five minutes before attempting a refresh in order to avoid DNS flooding.
|
Caution Please be aware that if using a cluster of Exinda appliances, the resolution for a given FQDN-Network Object, among the different appliances, might be unexpected if any of the following conditions are met:
|
|---|
|
|
|