Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[axeman72]

Hi All...

I have a DFL800 at work and a DFL200 at home. And I RTFM more than once to find the solution to a annoying "problem" (ok, it's a feature actually, but I need to turn it off) that I have on both machines: where is the "setting" that drops ICMP packets with TTL too low?

This, as an example, is the DFL200 at home...
tracert www.google.com
Tracing route to www.l.google.com [74.125.39.147]
over a maximum of 30 hops:
  1     *        *        *     Request timed out.
  2     *        *        *     Request timed out.
  3   104 ms    54 ms    46 ms  xe-10-2-0-278.mil-cal-score-2-re1.interoute.net
[89.202.175.249]
[...continue correctly until the final hop...]

First two hops fail. Always.

The DFL800 at work is worse: *EVERY* hop fails. Just the last hop is reported right. 

Both machines showed this behaviour from the first day, and I've almost abandoned all hopes...
Help please :-)

Thank you in advance.

CiaoCiaoSergio

[Fatman]

Ok, there are a few parts to this one.  I can only speak to the DFL-800, the DFL-200 is EOL and I haven't played with it in a long while.  That said I wouldn't be surprised if this info couldn't be generalized enough to help with any product.

Regardless, you are going to have to get the firewall itself to respond, figure out if your ISP GW is supposed to respond, and ensure the firewall isn't configured to drop TTL Low messages.

You need to go to the System->Advanced Settings page on your DFL-800 and ensure that it isn't set to drop TTL Low messages.

Then check the service/ALG applied to the traffic.

Test the ISP GW and ensure that it responds without a firewall in place.

***Modified by Fatman because he had a typo that created a factual fallacy.

[axeman72]

Thank you for the answer Fatman
Let's stay for now to the DFL800...

you are going to have to get the firewall itself to respond, figure out if your ISP GW is supposed to respond, and ensure the firewall isn't configured to drop TTL Low messages.

In the System/Advanced Settings/IP settings, the TTL low threshold is set to 0, so I think it shouldn't drop any packet. Now... 10.128.2.252 is the LAN IP, 89.xxx.xxx.XXX is the WAN IP and 89.xxx.xxx.YYY is the IP of my ISP GW.

This is a check of the shortest route in my network (ISP is not related to this problem, IMHO, because the router we replaced with DFL800 always worked) from a computer directly connected to DFL800 LAN:

> ping 10.128.2.252
Esecuzione di Ping 10.128.2.252 con 32 byte di dati:
Risposta da 10.128.2.252: byte=32 durata<1ms TTL=255

> ping 89.xxx.xxx.xxx
(timeout)

> ping 89.xxx.xxx.yyy
Esecuzione di Ping 89.xxx.xxx.yyy con 32 byte di dati:
Risposta da 89.xxx.xxx.yyy: byte=32 durata=1ms TTL=254

> tracert 89.xxx.xxx.yyy
Rilevazione instradamento verso 89.xxx.xxx.yyy su un massimo di 30 punti di passaggio
  1     *        *        *     Timeout.   
  2    <1 ms     1 ms    <1 ms  89.xxx.xxx.yyy


(sorry for italian cut&paste... I don't have a un-localized shell on this machine, but it should be understandable)


CiaoCiaoSergio

[Fatman]

Do you have log on TTL 0 enabled?
What is your TTL 0 action?
Do you see relevent log entries?

Are you using UDP or ICMP traceroute?

Do you have a distinct IP rule allowing the trace route traffic?
Does that IP Rule have a custom service?
Does that service have the "pass received ICMP error messages" option enabled?

I agree that your ISP is not the issue.

[Fatman]

Ohhh and don't worry about the Italian, I am a little bit of a language geek, seeing it was actually enjoyable.

I don't know any Italian, but I know a little Latin, Spanish, and French, as well as some others, so I am pretty sure I can handle an Italian console.  I don't know much of any of them, but they give an appreciation for romance languages.

Also I can see that console in my sleep in English, so I didn't even notice it wasn't in English till I started to detail-parse it.

[axeman72]

Sorry for late answer, I've been busy...

Do you have log on TTL 0 enabled?
What is your TTL 0 action?
Do you see relevent log entries?
Are you using UDP or ICMP traceroute?

Log Received TTL 0 is enabled
TTL Min is 0, and TTL on Low action is DropLog
No log entries about dropped packets due to TTL issues :-(
I'm using the "standard" windows XP traceroute, IIRC is an ICMP traceroute.

Do you have a distinct IP rule allowing the trace route traffic?
Does that IP Rule have a custom service?
Does that service have the "pass received ICMP error messages" option enabled?

Uhm... let's check...
#      Name      Action      SourceInterface      SourceNetwork      DestinationInterface      DestinationNetwork      Service
1     drop_smb-all    Drop     lan     lannet     wan1     all-nets     smb-all
2     allow_ping-outbound    NAT     lan     lannet     wan1     all-nets     ping-outbound
3     allow_ftp-passthrough    NAT     any     all-nets     any     all-nets     ftp-passthrough
4     allow_standard    NAT     lan     lannet     wan1     all-nets     all_tcpudp

I think Rule 2 is the one that let ICMP packets go from internal network to outside. Service "ping-outbound" is one of preloaded services, and in the description it says "Outbound ping (also allows traceroute via ICMP)" ... option "pass ICMP errors" is enabled.



(BTW about the same problem I had at home, I finally found the option on the DFL200 global policy settings: "drop packet with ttl lower than..." ... it was set to "3" ... I set it to "1" (0 is an illegal value for that machine) and solved the issue)


CiaoCiaoSergio

[Fatman]

Lets set your TTL On Low Action to either ignore or log.

Set the logging on your ping-outbound rule on and see if the tracert is triggering the right IP rule.