Tracert fails from inside a PIX firewall: misconfiguration?

What are the traceroute client platforms? More specifically, are they both using the same traceroute protocol?

This breaks EDNS0.

No it doesn't. RFC 2671 section 4.5.1 specifically allows for this behaviour:

4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP reassembly buffer. Choosing 1280 on an Ethernet connected requestor would be reasonable. The consequence of choosing too large a value may be an ICMP message from an intermediate gateway, or even a silent drop of the response message.

Thus as far as RFC 2671 is concerned, if you advertise that you can receive more than 512 bytes of payload and you cannot really do so because of something inbetween (e.g., your PIX configuration), then the fault is yours for having advertised that larger payload.

You are free to use EDNS0 with an advertisement of 512 bytes as your maximum size, thus gaining whatever other benefits there are to EDNS0 but retaining compatability with traditional DNS length restrictions.

Allow me to qualify my statement, then. This is a common cause of resolution failure due to the blocking of edns0 traffic. It will most likely break edns0 in any default edns0 implementation.

Not necessarily true. The sender may be unaware of a need for edns0 compatibility and block outgoing responses larger than 512.

If the sender is unaware of the need for edns0 compatability, then the packets sent back will not be in edns0 format and hence will not be larger than 512 bytes.

It is true, though, that it is possible for a DNS server to be configured for EDNS0 without the DNS admins or network admins realizing it is there, so the outgoing firewall could end up blocking longer packets without humans knowing what is going on.

Blocked large DNS packets are noted in the PIX logs (as one of the IDS signatures), but it is unfortunately common for people not to pay attention to their firewall logs until some substantial problem comes to their attention... if they thought to turn on logging in the first place...

Look at the way he spells "traceroute" ;-)

Yours, VB.

Yeah, noticed that. Though, the former and latter results certainly reflect icmp and udp traceroutes, respectively, as indicated at

The PIX has no effect on anything after the first hop. It is the way routing works,...each device along the way only determines what the "next hop" is and that is all. If a hop is failing,...then it is the caused by the last router it passed through trying to send the packet to another "gateway" that cannot, or will not receive the connection.

You need to explain the situation better. Pasting in tracerts into the message probably isn't going to do anything other than make the post impossible to read.

How does the VPN "fit in" to the picture? How does it (or even does it) relate to the target website?

Are then any situations where the Internal AD Domain Name is the same as the External Public Domain Name?

That was a pretty big version jump!

In this statement, is xxx.xxx.xxx.xxx the same as the IP of your outside interface? If so, then replace the IP address with the word "interface", as in

global (outside) 1 interface

What is the purpose of that route statement?

You are not going to be getting any 10/8 destinations converted from outside traffic, as none of your 'static' statements map to anything other than 10.10.10/24 .

You are not going to be getting any 10/8 traffic from the VPN tunnel, as your encrypt-acl does not permit 10/8 and you do not have any "reverse nat" statements that might nat the 200.57.135.113 traffic into

10/8 IPs.

You are not going to be getting any 10/8 traffic from inside that will be routed back to the inside interface, as PIX before 7.0 always discards traffic that comes in on an interface and is destined for the same interface.

Therefore, no traffic can flow that would be routed by that statement that would not already be routed by the 10.10.10/24 routing that the PIX is going to add automatically as the "connected" route based on the "ip address inside" statement.

The same reasoning is true for those two route statements.

There might be a few other subtle IP address problems, but in order to tell, I would need to see the configuration with unique munging of each IP address: as you have used xxx.xxx.xxx.xxx to represent several different IP addresses, I cannot tell whether there are conflicts.

Yes, both are tracert command for Windows XP SP2

Ok, may be it is a coincidence, but since tuesday I had troubles with the DNS server. It stopped resolving names. DNS server is located outside the firewall. I have another DNS server inside the firewall for the Windows 2000 domain but it is configured to forward all the requests to the outsider server. But it was impossible to resolve names from both inside and outside networks. I had to configure the outside server to forward the requests to another DNS server administrated by my ISP. Do you think I should delete the line "fixup protocol dns maximum-length

512" from the PIX configuration?

Thanks for your hints Sammy

Well, may be it is a coincidence but the remote node of the VPN, both unreachable web sites and the last hop that answers to the traceroute command, all they are on the same subnet 200.57.128/19.

Pre windows 2000 domain names are the same for the internal and external domains. Lets name it "mydomain". The full internal domain name is mydomain.net. The full external public domain is mydomain.com.mx. But the short domain name is mydomain for both. It is working in this configuration for +3 years without any problems.

Thanks Sammy

'traceroute' is the Unix/Linux command. you can always tell a Win/* user with the shortened form TRACERT :)

Yeah, noticed that.

Then they aren't the same. There is technically no such thing as a "short name". What you really have is the DNS based name (long) and the Netbios name (short) and they live in two different worlds. The Netbios names (short) do not "exist" on the external because the external is purely DNS only which is based on the FQDN (long) and since one ends with ".net" and the other ".com.mx",....they are therefore different.

But it isn't now.

I think your problem is that Hosts on the internal side are using a different DNS then what Hosts on the external side are using (that part is normal) and your internal DNS arrangement is not resolving the Site to the proper IP# that can be porperly reached by the LAN's routing setup. Your VPN may or may not be involved because there is just *way* too many things about your LAN that have not been clearly explained. Remember that I have no background knowledge of your LAN and I cannot "see" it in person for myself.