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

Traceroute, DNS failure

I've installed ASG 7.504 on an old Dell Celeron desktop, with 2 additional NIC's
eth2: BCM4400 
eth1: Intel 82557 e100 (not yet configured, future DMZ)
eth0: Intel 82557 e100 

Laptop  ASG  DSL modem

I'm able to ping :
laptop  ASG 
ASG -> ISP Gateway
laptop -> ISP Gateway

But none of the traceroutes are working, nor does DNS, from either laptop or ASG host.
I've enabled shell access (on Interal only) so that I can test from both ASG and laptop

I diligently checked each of the steps in the Astaro_V7_Quick_Start_Guide.pdf, everything seems golden right up to steps 7, 8 and 9.
The interfaces look fine (step 7 of the QuickStart), although the screen caps in the Quick Start Guide are a little different, probably a slightly older v7, no worries there.
My NAT rule is in place, Internal -> External.
I added the Internal network to the DNS service, but still nothing on either traceroute or DNS.
It is clearly a layer 4 issue, but I'm not sure if the default installation of Firewall rules, or static routes is the problem, or if it is one of the proxying services (which is why I want to try ASG)

Suggestions?

Thanks
R0d
(long time IPcop user... )


This thread was automatically locked due to age.
  • In WebAdmin. under Network Security > Packet Filter > ICMP tab, are youo allowing traceroute?
     
    Under Network Security > Intrusion Prevention > Advanced Tab, did you add your DNS server to Performance Tuning?
     
    Check your packet filter and IPS logs to see if you gets some hints about where the packets are being blocked.
    __________________
    ACE v8/SCA v9.3

    ...still have a v5 install disk in a box somewhere.

    http://xkcd.com
    http://www.tedgoff.com/mb
    http://www.projectcartoon.com/cartoon/1
  • Good tips. My packet filter is dropping my traceroute. My IPS log is clear (although the packetfilter shows plenty of drops already on the external... no surprise there)
    My previous configuration on the Network Security > Packet Filter > ICMP tab was the defaults:
    Global ICMP Settings
    [    ] Allow ICMP on firewall
    [    ] Allow ICMP through firewall
    [    ] Log ICMP redirects
    Ping settings
    [ x ] Firewall is Ping visible
    [ x ] Ping from Firewall
    [    ] Firewall forwards Pings
    Traceroute settings
    [    ] Firewall is Traceroute visible
    [ x ] Traceroute from Firewall
    [    ] Firewall forwards Traceroute

    I would expect that those settings would allow me to traceroute from the Firewall.
    I have temporarily checked all of these Global ICMP settings, Ping settings, Traceroute settings

    Same result, I'm not able to traceroute to my ISP gateway, although I can ping it.
    Tailing /var/log/packetfilter.log (and named.log) I get nothing, from either the traceroute or nslookup.

    Looking more at the DNS Performance Tuning now.
    Thx
  • Still getting nothing on either traceroute or nslookup.  Here are additional details.
    > Check your packet filter and IPS logs to see if you gets some hints about where the packets are being blocked. 

    I checked my packetfilter log, there are no hits for my internal IP, since I checked allow Traceroute. (as described above, all 3 ICMP, Ping, and Traceroute settings are still checked, for now)

    > Under Network Security > Intrusion Prevention > Advanced Tab, did you add your DNS server to Performance Tuning?

    Done.  Still nothing.
    My named.log file is *really* long - 4MB, 4417141 lines. Most of those lines are "too many timeouts resolving " errors, which doesn't point me at why DNS is failing.

    Let me recap... from the ASG firewall (shell):
    I can ping my ISP gateway, .1, but cannot traceroute to it.
    netstat -nr shows three lines, one for Internal, one for External, plus loopback.
    None of these lines has the default route flagged. This is in my experience, typically the last line of output from netstat -nr, like:
    Destination    Gateway     Genmask    Flags    MSS Window  irtt Iface
    0.0.0.0           (ISP gate)   0.0.0.0        UG            0  0             0 eth0

    That's what the final line on my ipcop box looks like, and I believe it is why nothing is going anywhere from ASG.
    I've looked at the Network > Interfaces and eth0 looks OK, the default GW box is checked, with the appropriate IP as gateway (Comment is added by installation wizard)
    I've looked at Network > Static Routing, and it looks OK, but I do not see any options to set a default route interface. I tried adding an interface route (the existing External (WAN) Network) -> Gateway ISP Gateway route is a Gateway route.

    I believe I could work out the command-line route command to define eth0 as my default gateway, but that would pretty much bypass the purpose of using the ASG suite.
    I tried creating a Policy Route to the Internet, but that did not help.

    So, 2 questions for the studio audience:
    1. Where (in ASG) do I set the route so that eth0 will get the UG flag?
    2. I've looked for a full manual (vs. the Quickstart guide) and have only found the v6 manual, if you have a pointer to that, I'd appreciate it.

    Thanks... I really want to like ASG, it seems very polished, but something fundamental is missing from my nearly-default installation.
    Rod
  • Still digging, but it seems I am not alone with this issue:
    https://community.sophos.com/products/unified-threat-management/astaroorg/f/53/t/32617
    I am finding the same E Failed: /sbin/ip route add error.
  • OK, it looks like I got the basics working...
    I deleted all the static routes (including those that were created by the default install.
    I checked the "Transparent" box on HTTP proxy.

    DNS is working properly both from ASG and the client.
    Traceroute still does not work from the client or from ASG (even though I have all the checkboxes enabled - Am turning those back off.) Perhaps this is disabled at the ISP gateway
    Ping works fine from both.
    HTTP appears to work fine from a DHCP client, through the proxy.