Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I know next to nothing about networking so apologies if this is a stupid or strange question.

Our systems administration/IT support is outsourced to a consulting company. I was working with them to try and figure out a routing issue. We have policy-based routing set up that should route any connection attempts to a certain IP range through a separate router. As I don't yet have the program that's going to be using this connection I was trying to verify it was set up correctly via tracert. The policy would sometimes correctly route it to the separate connection, with it being incorrectly routed with the catch-all internet connection policy the rest of the time.

The person I was working with from the consulting company couldn't figure it out, so he had to contact their rep at Watchguard. They determined it was caused by the default internet routing policy being ranked higher on the policy list than the specific IP range policy. When the problem continued after adjusting this, the rep went on to say that the firewall policies wouldn't be affecting any ping or tracert attempts anyways, and that any programs attempting to connect to an IP in the set range would be routed correctly.

I haven't had the chance to verify this yet with the particular application that will be using the connection. However I'm seeing some connection attempts to certain IPs randomly be routed to the separate connection when the IPs should not have triggered that policy. It seems like all of the policies are configured correctly so I would think this is a firewall issue. Does the rep's claim about firewall policies not affecting ping/tracert have any merit? I'll likely have to get in touch with them again about correcting this but I wanted to know in advance if this guy may or may not know what he's talking about.

share|improve this question
Standard ping and traceroute using ICMP rather than TCP or UDP. It's possibly your routing policy is only set up for TCP and UDP. – Paul Tomblin May 31 '11 at 15:00
up vote 1 down vote accepted

ping is using ICMP, normally traceroute generates either UDP or ICMP traffic (Unix/Windows difference). Hence, technically you should be able to easily discern diagnostic traffic from application generated one based on protocol used (assuming it's using TCP).

Therefore, it is possible that the routing policy is set to apply only to TCP traffic (as an example). So the statement in your question may be valid. But it would be a specific decision of the administrator. There should be no problem with applying the policy to all traffic, no matter the type, based on IP ranges. So if they wanted, the diagnostic traffic would use the same policy. In fact, I think it would be more reasonable to do so in the first place.

That said, the rep may have some merit, so you shouldn't dismiss him too early. But I would tread carefully, as the other problems you're mentioning (policy triggered when it shouldn't be) mean that probably there are some configuration issues. So it's equally probable that he may indeed not know what he's talking about.

share|improve this answer

Good answer by Karol Picza - you need to make the distinction between TCP, UDP and ICMP. As an additional point to help you troubleshoot, take a look at a linux toold called traceproto. It's quite similar to standard traceroute with the additional functionality of being able to specify a protocol and port, whereas standard traceroute only uses ICMP.

share|improve this answer
Thanks for the tool recommendation. We're an all MS shop, do you know any equivalent for Windows? – John Straka Jun 1 '11 at 10:44
Sorry, there's no Windows port for it. Pity about the Windows setup, there are some really fantastic Linux tools for network tracing. You could always use an Ubuntu live CD if you are interested. – Richard Keller Jun 1 '11 at 22:25

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.