Print

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

[m.pocius]

Hello,

I am new to this forum and to DFL-860E firewall.

Problem is that I can trace route to server that is behind DFL-860E firewall from other network, like my home, but I can't trace route from that server to other network.

When I try to traceroute to like google.com, everything is okay till last step. then it starts to fail:

Code: [Select]

root@hosting1 [~]# traceroute google.com
traceroute to google.com (195.12.176.34), 30 hops max, 60 byte packets
1  192-168-10-1.local.balticum.lt (192.168.10.1)  1.469 ms  0.806 ms  0.756 ms
 2  86-100-76-1-ip.balticum.lt (86.100.76.1)  2.639 ms  2.600 ms  2.530 ms
 3  klp-e01.int.balticum.lt (86.100.2.133)  2.593 ms  1.984 ms  1.794 ms
 4  213-190-33-57.telecom.lt (213.190.33.57)  3.371 ms  3.084 ms  2.886 ms
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
...
As far as I understand, trace route goes our of the server.

But when I try to trace route to server from other network I get:

Code: [Select]

C:\Users\Modestas>tracert 86.100.77.10

Tracing route to hosting1.cloudscop.com [86.100.77.10]
over a maximum of 30 hops:

  1     5 ms     1 ms     1 ms  Dlink-Router.Dlink [192.168.1.1]
  2     5 ms     1 ms     1 ms  192.168.0.1
  3     3 ms     2 ms     2 ms  hst-58-1.telelanas.lt [77.79.58.1]
  4     2 ms     2 ms     2 ms  hst-128-17.telelanas.lt [85.232.128.17]
  5     2 ms     2 ms     2 ms  86.100.2.38
  6     4 ms     4 ms     2 ms  klp-mc01.int.balticum.lt [86.100.2.134]
  7     3 ms     3 ms     2 ms  86-100-77-27-ip.balticum.lt [86.100.77.27]
  8     4 ms     5 ms     3 ms  hosting1.cloudscop.com [86.100.77.10]

Trace complete.

So the configuration, I have made:

I have connected server to LAN port.
Then I added local server IP address and Public IP address to InterfaceAddresses.
Then I added server IP to ARP:
    Publish    wan1    Server1_Public_Wan1    00-00-00-00-00-00
Then I created IP rules:
   1    cpanel-all-sat    SAT    any    all-nets    any    Server1_Public_Wan1    all_tcpudpicmp
   2    allow_standard    NAT    lan    lan_net    wan1    all-nets    all_tcpudpicmp
   3    cpanel-all-allow    Allow    any    all-nets    any    Server1_Public_Wan1    all_tcpudpicmp
Then I changed service "all_tcp", "all_udp" - I added a tic on "Pass returned ICMP error messages from destination"
Then I changed routing table:
   4    Route    wan1    Server1_Public_Wan1    wan1_gw    server1_local   100   No   
And last thing I changed was IP settings:
   TTL Min: 0
   Multicast TTL Min: 0
   TTL on Low: Log

This is all the configurations (adds and removals) I have made from factory defaults.

What can be the problem?

[m.pocius]

Any help would be appreciated.

[FurryNutz]

Link>Welcome!

Is there a main host router that the DFL is connected to or an ISP modem?
What Mfr and Model # are the ISP modem and or Main host router?

Can you provide a diagram of how you have the DFL and Server set up and connected?
Example:
ISP modem>Main Host Router>DFL>Server?

[m.pocius]

We have direct optical fiber from ISP. On that fiber we have four IPs. So stucture looks like this:

ISP -> DFL -> Server

[PacketTracer]

From your traceroute results one can at least draw the conclusion that the problem is not caused by your firewall, because you can reach '213-190-33-57.telecom.lt (213.190.33.57)' at step 4 when tracerouting from your server to google.com. This means that you could successfully send an ICMPv4 echo of TTL=4 to the 3rd router behind your firewall (the above mentioned telecom router) and receive the ICMP 'TTL exceeded' error response sent back from that router to your server - hence your firewall lets these packets pass.

If you don't receive responses from any further router down the path to google.com, this might be due to the administrators of that routers, who configured them not to send ICMPv4 error messages when dropping IP packets counted down to TTL=0 which is needed to make traceroute work. Did you wait for results beyond the 11th router in the path to google.com? At least google.com should reply as the last step in the chain. Did you try any other destinations, where pathes are different beyond the telecom router and other routers involved might hopefully reply?

I cannot judge your firewall configuration because I don't know this device and cannot understand the meaning of these cryptic configuration lines intuitively.

[m.pocius]

Thanks for reply.

I have tried a lot of destinations. I tied them with server and my computer in other network, and I can say that all traceroutes fails on the very last step of traceroute. I will try to contact our ISP.

[m.pocius]

I have found that this is not ISP's problem.

I have connected my laptop directly to line from ISP and traceroute works like a charm. So, there is something with router.

[PacketTracer]

Hi again,

your firewall has a lot of advanced settings. One I found when looking through the manual was the "Ping Idle Lifetime" with a default setting of 8 seconds.

The description of this paramater says: "Specifies in seconds how long a Ping (ICMP ECHO) connection can remain idle before it is closed."

Because with traceroute sent pings (icmp echoes) are never replied (you only receive ICMP TLL exceeded errors) your firewall might close your 'tracert session' after 8 seconds. Check if it helps to set the "Ping Idle Lifetime" to a value big enough, say 60 seconds. You will find this setting In the Web Interface under System > Advanced Settings.

PT

[Rara Avis]

Once upon a time someone in this forum had a similar concern, and the default settings on the DFL were a great point of contention, as I recall he had to make multiple changes for things like low TTL inbound and outbound, as well as changes to allow the DFL itself to respond to TTL low packets.

This must have been many years ago, good luck finding it.