Cisco Cisco Catalyst 6500 Series Firewall Services Module 故障排查指南
security−level 50
ip address 10.20.1.50 255.255.255.0
!
same−security−traffic permit intra−interface
access−list outside_in extended permit tcp any host 10.30.1.1 eq www
access−list inside_in extended permit ip any any
access−group inside_in in interface inside
access−group outside_in in interface outside
route outside 0.0.0.0 0.0.0.0 192.168.100.254
route dmz 10.30.1.0 255.255.255.0 10.20.1.254
Observed Behaviors
Connections from the client PC at 172.16.1.10 to the web server at 10.30.1.1 fail.
A packet capture on the outside interface shows a TCP SYN from the client PC arriving at the FWSM's
interface.
interface.
FWSM# show capture outside
3 packets seen, 3 packets captured
1: 13:58:09.280752960 802.1Q vlan#1 P0 172.16.1.10.57389 > 10.30.1.1.80: S
918518428:918518428(0) win 8192 <mss 1380,nop,nop,sackOK>
2: 13:58:12.280755950 802.1Q vlan#1 P0 172.16.1.10.57389 > 10.30.1.1.80: S
918518428:918518428(0) win 8192 <mss 1380,nop,nop,sackOK>
3: 13:58:18.280761960 802.1Q vlan#1 P0 172.16.1.10.57389 > 10.30.1.1.80: S
918518428:918518428(0) win 8192 <mss 1380,nop,nop,sackOK>
3 packets shown
A packet capture on the dmz interface does not show that packet leaving the firewall.
FWSM# show capture dmz
0 packet seen, 0 packet captured
0 packet shown
No entry is built in the FWSM's connection table and syslogs do not show any information related to the client
or server IP addresses.
or server IP addresses.
Triggers
At a fundamental level, this issue is caused by an entry in the FWSM's xlate table that was built by an
incorrectly routed packet. Because of the way the FWSM's packet processing is designed, the firewall checks
the xlate table before it checks the routing table to determine the egress interface. As a result, if a packet
matches an existing xlate the egress interface will be selected based on that entry, even if the entry conflicts
with what is listed in the routing table. In other words, the xlate table takes precedence over the routing table.
incorrectly routed packet. Because of the way the FWSM's packet processing is designed, the firewall checks
the xlate table before it checks the routing table to determine the egress interface. As a result, if a packet
matches an existing xlate the egress interface will be selected based on that entry, even if the entry conflicts
with what is listed in the routing table. In other words, the xlate table takes precedence over the routing table.
In order to diagnose this issue, check the output of the show xlate debug command:
FWSM# show xlate debug
Flags: D − DNS, d − dump, I − identity, i − inside, n − no random,
o − outside, r − portmap, s − static
3 in use, 3 most used
NAT from inside:10.30.1.1 to outside:10.30.1.1 flags Ii idle 0:00:00 timeout 3:00:00 connections 0
NAT from inside:10.30.1.1 to inside:10.30.1.1 flags Ii idle 0:00:07 timeout 3:00:00 connections 0
NAT from dmz:10.30.1.1 to outside:10.30.1.1 flags Ii idle 0:00:10 timeout 3:00:00 connections 0
Note: The debug keyword in the show xlate is crucial. Without it, the xlate entries will not include the
interface names that the entry is associated with.
interface names that the entry is associated with.