Validation of Interface Configuration
After the configurations are deployed to the threat defense, the hosts between the inside network and outside network should be able to communicate successfully. To test connectivity, you can simply run an ICMP ping test between the inside and outside hosts. If the hosts are running any services (such as web or Secure Shell), you can also use them to verify connectivity.
In a brand-new deployment, the management center does not display connection events. If you would like to use your management center to validate any connection attempts through your threat defense, you need to enable logging in the access control policy. By default, a new access control policy does not come with any customizable access control rule. Because we describe the operation of an access control rule in later chapters, for now, you can add a simple access control rule to allow the traffic and enable logging within that rule (see Figure 4-13). Alternatively, in an access control policy without any rule, you can simply enable logging in the default action (see Figure 4-14), which can also trigger connection events.
)
FIGURE 4-13 Enabling Logging Within an Access Control Rule
)
FIGURE 4-14 Enabling Logging in an Access Control Policy as a Default Action
If you deployed the access control policy with logging functionality enabled, you can now view events for any associated connections by navigating to Analysis > Connections > Events of your management center.
Figure 4-15 exhibits connection attempts from an inside host (IP: 192.168.1.2) to an outside host (IP: 172.168.1.2) over ICMP, SSH, and HTTPS protocols.
)
FIGURE 4-15 Table View of Connection Events Between Inside and Outside Hosts
While you run ICMP traffic, you can view the details of how the system is processing the ICMP packets by using the debug command.
Example 4-6 shows ICMP requests and replies exchanged between two computers located in the inside and outside networks.
Example 4-6 Debugging ICMP Traffic in a Threat Defense
> debug icmp trace debug icmp trace enabled at level 1 > ICMP echo request from INSIDE_INTERFACE:192.168.1.2 to OUTSIDE_INTERFACE:172.16.1.100 ID=4101 seq=1 len=56 ICMP echo reply from OUTSIDE_INTERFACE:172.16.1.100 to INSIDE_INTERFACE:192.168.1.2 ID=4101 seq=1 len=56 ICMP echo request from INSIDE_INTERFACE:192.168.1.2 to OUTSIDE_INTERFACE:172.16.1.100 ID=4101 seq=2 len=56 ICMP echo reply from OUTSIDE_INTERFACE:172.16.1.100 to INSIDE_INTERFACE:192.168.1.2 ID=4101 seq=2 len=56 . . <Output Omitted> > undebug all >
If the ping test fails, you need to determine the status of the interfaces. You can run the following commands on the threat defense to determine the interface status and to verify the configurations you applied from the management center to the threat defense. Command outputs are slightly different depending on the configuration method (static versus dynamic).
show ip
show interface ip brief
show interface interface_ID
show running-config interface
Example 4-7 shows output of the show ip command. You can view the mapping between the interface, logical name, and IP address in this output. You cannot, however, view the current status in the output.
Example 4-7 Output of the show ip Command
> show ip System IP Addresses: Interface Name IP address Subnet mask Method GigabitEthernet0/0 INSIDE_INTERFACE 192.168.1.1 255.255.255.0 CONFIG GigabitEthernet0/1 OUTSIDE_INTERFACE 172.16.1.1 255.255.255.0 CONFIG Current IP Addresses: Interface Name IP address Subnet mask Method GigabitEthernet0/0 INSIDE_INTERFACE 192.168.1.1 255.255.255.0 CONFIG GigabitEthernet0/1 OUTSIDE_INTERFACE 172.16.1.1 255.255.255.0 CONFIG >
Example 4-8 confirms that both the GigabitEthernet0/0 and GigabitEthernet0/1 interfaces are up and configured manually (using static IP addresses). The show interface ip brief command provides an overview, including the current status, of each of the interfaces.
Example 4-8 Overview of the Interface Status
> show interface ip brief Interface IP-Address OK? Method Status Protocol GigabitEthernet0/0 192.168.1.1 YES CONFIG up up GigabitEthernet0/1 172.16.1.1 YES CONFIG up up GigabitEthernet0/2 unassigned YES unset administratively down up GigabitEthernet0/3 unassigned YES unset administratively down up GigabitEthernet0/4 unassigned YES unset administratively down up GigabitEthernet0/5 unassigned YES unset administratively down up GigabitEthernet0/6 unassigned YES unset administratively down up GigabitEthernet0/7 unassigned YES unset administratively down up Internal-Control0/0 127.0.1.1 YES unset up up Internal-Control0/1 unassigned YES unset up up Internal-Data0/0 unassigned YES unset down up Internal-Data0/0 unassigned YES unset up up Internal-Data0/1 169.254.1.1 YES unset up up Internal-Data0/2 unassigned YES unset up up Management0/0 unassigned YES unset up up >
Example 4-9 shows detailed statistics of the GigabitEthernet0/0 interface. By using the show interface interface_ID command, you can determine any errors and drops that may have occurred on an interface.
Example 4-9 Detailed Statistics of Packets in the Interface Level
> show interface GigabitEthernet 0/0
Interface GigabitEthernet0/0 "INSIDE_INTERFACE", is up, line protocol is up
Hardware is net_vmxnet3, BW 10000 Mbps, DLY 10 usec
Auto-Duplex(Full-duplex), Auto-Speed(10000 Mbps)
Input flow control is unsupported, output flow control is unsupported
MAC address 000a.000b.abcd, MTU 1500
IP address 192.168.1.1, subnet mask 255.255.255.0
277 packets input, 60997 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 pause input, 0 resume input
0 L2 decode drops
215 packets output, 77346 bytes, 0 underruns
0 pause output, 0 resume output
0 output errors, 0 collisions, 0 interface resets
0 late collisions, 0 deferred
0 input reset drops, 0 output reset drops
input queue (blocks free curr/low): hardware (0/0)
output queue (blocks free curr/low): hardware (0/0)
Traffic Statistics for "INSIDE_INTERFACE":
277 packets input, 57079 bytes
215 packets output, 74336 bytes
7 packets dropped
1 minute input rate 0 pkts/sec, 0 bytes/sec
1 minute output rate 0 pkts/sec, 0 bytes/sec
1 minute drop rate, 0 pkts/sec
5 minute input rate 0 pkts/sec, 0 bytes/sec
5 minute output rate 0 pkts/sec, 0 bytes/sec
5 minute drop rate, 0 pkts/sec
>
Example 4-10 displays the interface configurations from the CLI. You can find all the settings you configured on the management center and applied to the threat defense.
Example 4-10 Running Configurations of GigabitEthernet0/0 and GigabitEthernet0/1
> show running-config interface ! interface GigabitEthernet0/0 nameif INSIDE_INTERFACE cts manual propagate sgt preserve-untag policy static sgt disabled trusted security-level 0 ip address 192.168.1.1 255.255.255.0 ! interface GigabitEthernet0/1 nameif OUTSIDE_INTERFACE cts manual propagate sgt preserve-untag policy static sgt disabled trusted security-level 0 ip address 172.16.1.1 255.255.255.0 ! interface GigabitEthernet0/2 shutdown no nameif no security-level no ip address . . <Output Omitted for Brevity> . . >
If the threat defense does not offer an IP address to its DHCP clients, or if the threat defense cannot obtain an IP address from any external DHCP server, you can debug any DHCP transactions to and from the DHCP server.
Example 4-11 proves that the threat defense has dynamically assigned the IP address 192.168.1.2 to a host with the MAC address C4:2C:03:3C:98:A8. This IP address is the first address from the DHCP address pool 192.168.1.2 to 192.168.1.10.
Example 4-11 Verifying the IP Address Assignment from a DHCP Address Pool
> show dhcpd binding IP address Client Identifier Lease expiration Type 192.168.1.2 c42c.033c.98a8 3580 seconds Automatic >
If you do not see any DHCP binding, you can debug the DHCP packets on the threat defense.
Example 4-12 demonstrates the process of a DHCP server assigning an IP address. In the debug output, you can analyze the four major stages of the DHCP protocol: Discovery, Offer, Request, and Acknowledgment (DORA).
Example 4-12 Exchange of DHCP Packets Between a Threat Defense and a DHCP Server
> debug dhcpd packet debug dhcpd packet enabled at level 1 > DHCPD/RA: Server msg received, fip=ANY, fport=0 on INSIDE_INTERFACE interface DHCPD: DHCPDISCOVER received from client c42c.033c.98a8 on interface INSIDE_INTERFACE. DHCPD: send ping pkt to 192.168.1.2 DHCPD: ping got no response for ip: 192.168.1.2 DHCPD: Add binding 192.168.1.2 to radix tree DHCPD/RA: Binding successfully added to hash table DHCPD: Sending DHCPOFFER to client c42c.033c.98a8 (192.168.1.2). DHCPD: Total # of raw options copied to outgoing DHCP message is 0. DHCPD/RA: creating ARP entry (192.168.1.2, c42c.033c.98a8). DHCPD: unicasting BOOTREPLY to client c42c.033c.98a8(192.168.1.2). DHCPD/RA: Server msg received, fip=ANY, fport=0 on INSIDE_INTERFACE interface DHCPD: DHCPREQUEST received from client c42c.033c.98a8. DHCPD: Extracting client address from the message DHCPD: State = DHCPS_REBOOTING DHCPD: State = DHCPS_REQUESTING DHCPD: Client c42c.033c.98a8 specified it’s address 192.168.1.2 DHCPD: Client is on the correct network DHCPD: Client accepted our offer DHCPD: Client and server agree on address 192.168.1.2 DHCPD: Renewing client c42c.033c.98a8 lease DHCPD: Client lease can be renewed DHCPD: Sending DHCPACK to client c42c.033c.98a8 (192.168.1.2). DHCPD: Total # of raw options copied to outgoing DHCP message is 0. DHCPD/RA: creating ARP entry (192.168.1.2, c42c.033c.98a8). DHCPD: unicasting BOOTREPLY to client c42c.033c.98a8(192.168.1.2). >