Trouble Shooting Guide (network connectivity)

Version 2

    This trouble shooting guide aims to get you connected to the internet via a UTM Firewall and make sure the services you want working through the UTM firewall are working ok. It is written from a Murphy's law perspective - everything that could possibly go wrong has gone wrong, and we're going to fix it one step at a time.

     

    This is a work in progress. Murphy's law applies to this document too after all - so if we missed anything - let us know and we'll add it in!

     

    It is acknowledged that the world outside this guide contains more than just windows-PC's - all the same rules and solutions apply its all TCP/IP after all - the tools just have different names.

     

    Where the author has rashly typed 'tcpdump' you may also use 'Diagnostics -> Packet Capture', Wireshark or similar depending on which device you need it on.

     

    1) PC has no network connectivity

    Windows is reporting 'no link' or 'no connection'. Check the cable and make sure both ends are securely plugged in. You may laugh, but with lots of cables floating around sometimes those tiny plastic lugs get snapped off and if you're too busy (ahem) to fix it or find a new cable, then strange things can happen.

     

    2) PC has link but nobody is home

    Your PC has allocated a 169.... IP addr that you've never seen before, or is outright refusing to assign an IP-address.

    Chances are you are set up for 'automatic' configuration in this case, and the reason there is no joy is because your DHCP server is not talking to you.

     

    Since you already checked your PC connectivity, now go and check that your DHCP server (perhaps your UTM appliance) is similarly connected.

    Find a computer that is working properly and log into the UTM web-admin interface. check that there are enough leases left to hand out an address

    to your PC. If not, add some leases.

     

    If that's not it, things get tricky from here. Really you need to do a tcpdump (packet-dump) to see if DHCP broadcasts and/or ARP requests are

    getting through to/from your PC.

     

    3) PC has an IP-addr but can not connect to any computers on the LAN

    Its unlikely that the PC can communicate to the DHCP server (probably via a network switch) is not able to send packets to other systems on the LAN.

     

    Check that the other computers have the same subnet configuration, and that nothing strange has been done to the switch. eg. some sites like to

    partition switches with different vlan segments.

     

    Try to ping one of the other computers via its IP-address (walk over, find out what it is first). If ping does not work, check whether or not

    the ARP cache has anything in it: run 'arp -a' or similar from cmd.exe

     

    You can use wireshark on the PC to see more (packet-capture) but also consider running tcpdump on the UTM Firewall to see if any ARP

    packets are being seen by it. Since ARP packets are broadcasts, the UTM firewall should see all/most of them even though you are in a

    switch environment (its in fact an attack vector while hacking on LANs, as it happens).

     

    4) PC talks fine on the LAN but can not talk to the internet

    Check that your PC has DNS configured properly. 'ipconfig /all' should list the address of the DNS server that your DHCP server

    has given you (or that you configured manually). Make sure you can 'ping' that DNS IP-address. If not debug as per above to find out

    why you can not reach it.

     

    Now that you know that your DNS requests are likely reaching the DNS server, check that you can look up something.

    There are two ways to do that on windows. 'ping google.com' (or similar) will do a DNS lookup for google.com and then

    display the result in the output of the command. This lookup usually goes through the DNS cache that is normally turned on for windows.

    The windows DNS cache can get confused. So if google.com is not resolved, try the 'nslookup' tool instead. As it doesn't go through the

    cache it will tell you whether or not the cache is confused or something is wrong with the DNS server.

     

    If you suspect the DNS cache is stuffed, just flush it and it should come back to life again

        ipconfig /flushdns

     

    If you are using a DNS server other than UTM Firewall, check that the default 'drop outbound DNS' rule on the UTM Firewall is disabled.

    Its a good idea to point your DNS at the UTM Firewall and then let it cache requests for you and 'be nice'. Then you can leave the DNS-block in place which stops anybody from re-programming (viruses/worms) your PC to talk to 'their' DNS server. Why would they do that? well, if you 'google.com' and I can force your PC to contact _my_ server instead of 'google.com' then I can see what your are googling. Or banking. Phishing its called. You don't want it. So be sure that you really need access to 'special' DNS servers before disabling the UTM firewall rule that is there to protect you. Rather, configure UTM firewall to talk to 'that' DNS server for you. That way its much harder for people to mess with your DNS setup - and your entire network will be much safer as a result.

     

    If DNS requests resolve fine, but your 'ping google.com' is not getting any packets back, check the gateway. again use 'ipconfig /all' and check which default gateway is listed there.

    ping that default gateway - if you can't ping it, then its broken, use the above steps to figure out why you can not get to the default gateway.

     

    In really tricky situations you might actually have routes installed that cause problems. So when things get really weird, its a good idea to check

    your routing tables

       'route print'

    Look at the leftmost two columns and the ip address you are trying to ping to determine of any of the routes might be forcing your packets

    to be sent to a gateway that you didn't know about - then debug that path.

     

    If you can ping the gateway ok, but nothing is coming back still - then use the

      tracert -d google.com

    command to figure out where packets are getting stuck. consider using the '-w 1' option in there to speed things up a bit. You're only interested in the first few hops - eg. until you've reached your ISP - because after that its mostly out of your control anyway.

     

    If you are not getting out of the other side (wan side) of your UTM Firewall, check why it is blocking things.

     

    5) you think UTM firewall is blocking your outbound traffic

    First, check that your packets are not being dropped. Go to Diagnostics->Syslog and look for 'Drop' messages. Check that they are not in relation to your PC.

    If they are, see if you can determine from the log message which firewall rule is doing it and why it might be in place.

     

    If there are no log messages, check that the UTM Firewall can at least see the internet. Go to the Diagnostics menu and you will find ping, traceroute and friends under networking tools. To see the current configuration check for interfaces and routes on the main diagnostics page. Or you can ssh/telnet into the CLI and play with ifconfig, route, traceroute, tracepath and similar to achieve the same.

     

    The debug process to get the internet link up is the same as for the PC.

     

    If the PC can still not see the internet, go and check where the packet is going. a tcpdump 'any' is good for that as it should tell you which interface the packet is going out on. And if its not going out anywhere, then you should check your firewall rules again. Either way you will track down where the packet is being routed to or dropped from eventually.

     

    And that is, basically, how it is done.

     

    Any feedback suggestions appreciated.