This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

[5.012] Firewall is Traceroute visible NOT working

On 5.012, I have
"Firewall is Traceroute visible" enabled.

It works if I do a traceroute to any of ASL's interfaces.

However,
If I traceroute from INT to a machine in the DMZ, I get:

Code:
C:\>tracert 10.0.0.10

Tracing route to linux [10.0.0.10]
over a maximum of 30 hops:

  1     *        *        *     Request timed out.
  2   

 

The DMZ server shows up but the firewall does not.

The packetfilter log shows:
 Code:
2004:06:27-11:26:44 (none) kernel: DROP: IN= OUT=eth0 SRC=192.168.11.1 DST=192.168.11.13 LEN=120 TOS=0x00 PREC=0xC0 TTL=64 ID=44735 PROTO=ICMP TYPE=11 CODE=0 [SRC=192.168.11.13 DST=10.0.0.10 LEN=92 TOS=0x00 PREC=0x00 TTL=1 ID=26162 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=25856 ] 



192.168.11.1 is the firewall, 11.13 is the PC.

It looks to me like the REPLY packets are getting dropped by the firewall for some reason.

Thanks,
Barry


This thread was automatically locked due to age.
  • I'm emailing support now since no one seems to be looking into this and it's been 3.5 months!

    Barry
  • hallo, it work´s with 5.025, 
    but the Default-GW from the PC mustbe the ASTARO
  • Astaro is my default gateway, of course.

    You're saying you can traceroute to a remote host, and the astaro hop responds?
    Are you using Masquerading?

    Thanks,
    Barry
  • Any updates on this?

    I'm using 5.027 and have all icmp options enabled in
    Packet Filter-> ICMP

    Traceroute direct to firewall:
     Code:
     
    
    Tracing route to asl.domain.tld [192.168.1.1]
    over a maximum of 30 hops:

      1    

     


    Traceroute to internet:
     Code:
     
    
    Tracing route to www.astaro.org [212.126.210.204]
    over a maximum of 30 hops:

      1     *        *        *     Request timed out.
      2    42 ms    30 ms    31 ms  XXX.XXX.XXX.XXX
      3    32 ms    32 ms    31 ms  XXX.XXX.XXX.XXX
     



    UPDATE:
    Seem to work after all. At least the second time I do it.

    Fir time it fails and this shows up in the log:
    Code:
     
    
    18:21:24  asl.ip.ip.ip  TTL exceeded  ->  workstation.ip.ip.ip    ICMP  28  92  64  [SRC=workstation.ip.ip.ip DST=traceroute.ip.ip.ip TOS=0x00 PREC=0x00 TTL=1 ID=42769 PROTO=ICMP TYPE=8 CODE=0 ID=768 SEQ=31488 ]  

     
  • Still not working for me in 5.027

    Traceroute to firewall works, but traceroute to DMZ or Internet gets timeouts on the ASL hop.

    I've emailed support, but they said they won't provide support without a contract. I find this frustrating as I believe it's a bug and they should try to fix it.

    Can you email support also?

    Here's what I get with a traceroute from DMZ to INT (INT to DMZ looks the same):
    Code:

    > traceroute 192.168.11.13
    traceroute to 192.168.11.13 (192.168.11.13), 30 hops max, 38 byte packets
     1  * * *
     2  bjg (192.168.11.13)  1.100 ms  1.121 ms  0.993 ms

    packetfilter.log:
    2004:11:19-10:48:21 (none) kernel: DROP: IN= OUT=eth2 SRC=10.0.0.254 DST=10.0.0.10 LEN=66 TOS=0x00 PREC=0xC0 TTL=64 ID=59484 PROTO=ICMP TYPE=11 CODE=0 [SRC=10.0.0.10 DST=192.168.11.13 LEN=38 TOS=0x00 PREC=0x00 TTL=1 ID=52443 PROTO=UDP SPT=52442 DPT=33435 LEN=18 ] 
    2004:11:19-10:48:26 (none) kernel: DROP: IN= OUT=eth2 SRC=10.0.0.254 DST=10.0.0.10 LEN=66 TOS=0x00 PREC=0xC0 TTL=64 ID=59527 PROTO=ICMP TYPE=11 CODE=0 [SRC=10.0.0.10 DST=192.168.11.13 LEN=38 TOS=0x00 PREC=0x00 TTL=1 ID=52444 PROTO=UDP SPT=52442 DPT=33436 LEN=18 ] 
    2004:11:19-10:48:31 (none) kernel: DROP: IN= OUT=eth2 SRC=10.0.0.254 DST=10.0.0.10 LEN=66 TOS=0x00 PREC=0xC0 TTL=64 ID=59589 PROTO=ICMP TYPE=11 CODE=0 [SRC=10.0.0.10 DST=192.168.11.13 LEN=38 TOS=0x00 PREC=0x00 TTL=1 ID=52445 PROTO=UDP SPT=52442 DPT=33437 LEN=18 ]

     

    Barry 
  • just for the record, I have not had any problems with this after up2dating to 5.100 [:)]
  • Yep, working now for me too.

    Thanks,
    Barry
  • As a postscript, I'd like to mention that I wasn't treated very well by support on this... 
    I emailed it as a bug to support, not asking for personal assistance.

    I got an email back saying I'd have to pay for support if I wanted help with this "configuration issue".

    It is now clear that this was a bug and not a configuration issue.

    I think Astaro needs to look into bug reports a little more thoroughly and promptly, and not wait 6 months to fix something like this.

    It's the little bugs like this that have been holding me back from upgrading our (licensed) production firewall, and the attitude isn't helping anyone.

    Thanks,
    Barry