3

I'm having some strange issues with traceroute. I have seen this happen before, but never on my local network. When I run traceroute to a host that is litterally one hop away on my lan, this is the result.. 30 hops of nothing. It also happens whether or not I am connected to my VPN server.

traceroute to 192.168.154.115 (192.168.154.125), 30 hops max, 60 byte packets
1  * * *
2  * * *
3  * * *
 ---etc...
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

I do have ICMP time exceeded and echo request enable on both my local, router's and, vpn's firewall. This happens with both the -U and -T flags as well. What would explain traceroute failing like this? It happens on any host in my network. Hosts that are not online from the lan subnet get sent to my VPN server for some reason as well:

tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 1600 bytes
01:49:06.279282 IP (tos 0xc0, ttl 64, id 45407, offset 0, flags [none], proto ICMP (1), length 88)
    10.8.0.1 > 10.8.0.4: ICMP time exceeded in-transit, length 68

I feel like my computer is not routing correctly but my routing table looks fine. I can reach those hosts just fine. The reason why this is concerns me is serveral times during the last month or so, both arpwatch and redis-server were spontaneously enabled on my computer after an update, I have never used those programs, and Kali disables network services by default, I believe. Should I be concerned about any of this? What would explain the failure of traceroute?

Edit: Okay here are the routing tables of the router & both clients I am trying to traceroute:

router (192.168.154.1)

:~$ route

Destination     Gateway         Genmask         Flags Metric Ref    Use     Iface
default         10.2.0.1        0.0.0.0         UG    0      0        0 wlan0
10.2.0.0        *               255.255.255.0   U     0      0        0 wlan0
192.168.154.0   *               255.255.255.0   U     0      0        0 br-lan

client (my comuter)

:~$ route

default         192.168.154.1   0.0.0.0         UG    0      0        0 eth0
192.168.154.0   *               255.255.255.0   U     0      0        0 eth0


:~$ traceroute 192.168.154.115


traceroute to 192.168.154.115 (192.168.154.115), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 --- snip--
 30  * * *

other client (another computer on my lan)

:~$ route

default         Openwrt.local   0.0.0.0         UG    0      0        0 eth0
192.168.154.0   *               255.255.255.0   U     0      0        0 eth0


:~$ route -n


default         192.168.154.1   0.0.0.0         UG    0      0        0 eth0
192.168.154.0   *               255.255.255.0   U     0      0        0 eth0
Community
  • 1
nemister
  • 31
  • Maybe the router does not decrease the TTL? – Konrad Gajewski Jul 11 '15 at 08:20
  • What would cause that and how would I go about fixing it? I am running openwrt. –  Jul 11 '15 at 17:45
  • 1
    I'm not sure there is an InfoSec question here. This is a networking question. – schroeder Jul 12 '15 at 02:46
  • 1
    Please provide your routing tables for your source and destination. My initial thought is your iptables is preventing ICMP response. – CIA Jul 12 '15 at 16:02
  • Local traffic shouldn't transit your router. If it does, something is very wrong. What is the client Operating System of the hosts you're trying to tracert? Are the host firewalls configured correctly to allow your tracert and/or pings? – joeqwerty Jul 14 '15 at 01:55
  • Is it possible that you are in a double NAT situation? I have seen similar issues in the past while in a double NAT environment but can not be 100% certain that it was the cause of the issue... – Matt Jul 14 '15 at 02:11
  • Where would this NAT be occurring? Why would it be occurring? Local traffic should be neither routed nor NAT'ed. – joeqwerty Jul 14 '15 at 02:19

1 Answers1

0

I ended up completely reflashing the firmware from scratch, and now all these problems are gone. Traceroute works again and the network is functioning correctly again. I am going to assume that the configuration was messed up and that's what caused this.

By the way, a couple of my edits were rejected today, I'm guessing because they came from another acct, which may have confused someone. When I posted this question originally on security.stackexchange, I was logged on to a different account. Sorry for the confusion there.

nemister
  • 31