I have been testing traceroutes through the PIX and found an interesting anomaly. Current architecture for testing is:
interent(1.1.1.1) -> pix(2.2.2.2) -> router(3.3.3.3) -> host(4.4.4.4)
When performing a traceroute from the internet to the host the following occurs:
1. The pix is transparent, as it should be.
2. The router responds with TTL time exceeded, as it should. I verified this with a sniffer.
3. The host responds with port unreachable, as it should. Again a sniffer.
The problem is the client who performed the traceroute sees something different. It sees the second to last hop with a source IP address of the host and it sees the last hop as the host as well. For example:
It should look like this on the last two hops:
...
7 3.3.3.3 10ms 10ms 10ms
8 4.4.4.4 10ms * 10ms
But it looks like this:
...
7 4.4.4.4 10ms 10ms 10ms
8 4.4.4.4 10ms * 10ms
** I relaize that the asterik occurs because some OS's (including Cisco IOS) will not send two icmp ttl exceededs within 500 ms of eachother.
I have verified, with a sniffer, that the destination host only responds with two icmp TTL exceeded messages. I have also verified that the router responds with three icmp port unreachables with its own source address. When received at the client station though, the source address has changed to that of the host.
It looks like the PIX is changing the IP address of any port unreachable messages to that of the destination host. Has any else observed this behaviour?
If Cisco has written this into the code for security reasons then they better think again. If this is true and I do not have a problem on my side, then Cisco has provided a mechanism for fingerprinting the firewall.
Kevin
