Cisco Cisco Catalyst 6500 Series Firewall Services Module 故障排查指南

下载
页码 7
The xlate table shows that there are 3 xlates built for the web server. The first xlate is built between the inside
interface and the outside interface. The second xlate is built as a hairpinned or u−turned xlate on the inside
interface. The third xlate is built between the dmz and the outside interface. The I flag indicates that this is an
identity xlate and the IP is not actually being translated.
The first interface listed in the entry is the "real" or "local" interface where the IP is supposed to actually exist.
The second interface listed is the "mapped" or "global" interface where the IP is being translated. Neither of
these xlates shown are correct. This is because the web server (10.30.1.1) actually exists behind the dmz
interface. The third xlate is correct for this network design.
The connection failure occurs because of the first xlate listed in the table. When the client's TCP SYN packet
arrives on the outside interface destined to 10.30.1.1, the FWSM checks the xlate table and matches the first
entry. This entry indicates that the packet should egress on the inside interface, which is incorrect, and the
packet is blackholed.
By default, the FWSM will automatically build an identity xlate for any traffic that does not match an
explicitly configured NAT rule. Because of this, even if a packet erroneously arrives on an incorrect interface,
an xlate will be built. Specifically for this case, packets sourced from 10.30.1.1 arrived inbound on the inside
interface instead of arriving on the dmz interface as is expected.
The first xlate (inside > outside) was built when the web server tried to ping a non−existent IP address
(10.199.199.1). The echo request left the web server destined to its default gateway (the DMZ router). The
DMZ router forwarded the packet toward the inside router, per its static route:
S       10.0.0.0/8 [1/0] via 10.50.1.254
Because the 10.199.199.0/24 network does not actually exist anywhere, the inside router simply follows its
default route and sends the packet to the FWSM's inside interface:
S*   0.0.0.0/0 [1/0] via 10.20.1.50
Likewise, the FWSM also does not have a route for the destination network. Therefore, it selects the outside
interface as the egress interface and builds an identity xlate from inside > outside:
S    0.0.0.0 0.0.0.0 [1/0] via 192.168.100.254, outside
The second xlate (inside > inside) was built when the web server tried to access the DNS server while the
inside router's 10.40.1.254 interface was temporarily down due to a link flap. The DNS request left the web
server destined to its default gateway (the DMZ router). The DMZ router forwarded the packet toward the
inside router, per its static route:
S       10.0.0.0/8 [1/0] via 10.50.1.254
However, the inside router's interface connected to the 10.40.1.0/24 network was temporarily down and its
directly connected route for this network was missing. Therefore, the only matching route in the routing table
was the default route back toward the FWSM:
S*   0.0.0.0/0 [1/0] via 10.20.1.50
The packet was routed to the FWSM's inside interface. The FWSM's routing table indicated that the
destination network of 10.40.1.0/24 existed behind the same inside interface:
S    10.40.1.0 255.255.255.0 [1/0] via 10.10.1.254, inside