Can I trust traceroute on this?

Hello.
A friend of mine has a VPN linking it’s home and office networks, in a somewhat complex structure (please see schematics.pdf). The VPN is implemented by two Dreytek routers, and should be completely transparent to SuSE.
Well, he can’t ping from his office to his home computers (though he can do it the other way around!); I suspect the problem lies somewhere in the routers’ configuration. I did a traceroute from office to home and got the output shown on traceroute.txt.

As you can see, the last internal checkpoint on the trace is 192.168.1.254; after that, it dives on the unknown.
So my question is simply this: can I really be sure that the packets never got to the Linux machine (192.168.1.150), or is there any reason for Windows 2008 Server’s traceroute shouldn’t be trusted?

Thanks to all.

Some routers block traceroute. You can use the “-I” flag so that traceroute then operates with the same kind of packets used by “ping”. But then some routers block ping.

Actually, I’m using Windows’ “tracert” that has no -I flag. Nevertheless, I can’t see how that would help; if you open the traceroute.txt file you’ll notice that it goes nuts only after arriving 192.168.1.254, ie Router B. So, I think we can assume that the routers aren’t blocking the tracert’s packets.

Thanks for responding.

Windows does the equivalent of always using the “-I” flag.

I wouldn’t call it “going nuts”. Timeouts are common with traceroute. If those 10.x.x.x addresses are not yours, then they ISP routers somewhere.

nrickert wrote:
> fmart8;2399506 Wrote:
>> Nevertheless, I can’t see how that would help; if you open the
>> traceroute.txt file you’ll notice that it goes nuts only after arriving
>> 192.168.1.254, ie Router B.
> I wouldn’t call it “going nuts”. Timeouts are common with traceroute.
> If those 10.x.x.x addresses are not yours, then they ISP routers
> somewhere.

If I’m reading the trace right, step 1 is Router A, step 2 is Router B,
then there are the mysterious 10.* addresses. So AFAICT either:

(1) the 10.* addresses are internal to site B but not shown on the diagram

(2) 192.168.1.254 isn’t really Router B, connected as shown

(3) Router B isn’t routing the packets into place B but instead is
passing them back out to some ISP that is grossly mishandling them!

(4) Router B is hallucinating

(5) something else?

Thanks for responding, djh-novell.
Unless I’m completely mistaken, the 10.* addresses aren’t internal and 192.168.1.254 really is router B.
So, you’d agree that the given data suggests that the problem happens before the Linux Server, as apparently the packets never do arrive there?

Thanks.

Well, I only mentioned that fruit ( :slight_smile: ) because those 10.* addresses are «alien». Thanks for responding.

It seems to be fairly common for ISPs to use 10.x.x.x IP addresses in their internal infrastructure. And since your packets go through that infrastructure to reach the Internet, those IP addresses can show up on traceroutes. In other forums, I sometime see people worrying because their router log reports an attack from 10.x.x.x IP addresses. That “attack” usually turns out to be a background of DHCP traffic on their segment of the ISP network.

fmart8 wrote:
> Thanks for responding, djh-novell.
> Unless I’m completely mistaken, the 10.* addresses aren’t internal and
> 192.168.1.254 really is router B.
> So, you’d agree that the given data suggests that the problem happens
> before the Linux Server, as apparently the packets never do arrive
> there?

I think I’d be inclined to get some more data before trying to draw any
conclusions.

For example, traceroute from the various machines on network B to
somewhere on A. traceroute from other machines plugged in on network A
to various places.

wireshark on network B to see if the traceroute packets are really there.

Whatever can be obtained by inspecting the routers (traffic logs,
routing tables, settings etc)

I don’t know anything about VPNs so there may be some information to be
extracted from the VPN.

Check the route for 192.168.10.0/24 on router B. It should point to 192.168.1.150 from the drawing.

I’m guessing there is no route for that destination configured on router B and it hits the default route. You can also check that and see if the default route on router B points to 10.42.191.254.

Best regards,
Greg

On 11/02/2011 07:16 AM, nrickert wrote:
>
> fmart8;2399703 Wrote:
>> Well, I only mentioned that fruit ( :slight_smile: ) because those 10.* addresses
>> are «alien».
> It seems to be fairly common for ISPs to use 10.x.x.x IP addresses in
> their internal infrastructure. And since your packets go through that
> infrastructure to reach the Internet, those IP addresses can show up on
> traceroutes. In other forums, I sometime see people worrying because
> their router log reports an attack from 10.x.x.x IP addresses. That
> “attack” usually turns out to be a background of DHCP traffic on their
> segment of the ISP network.

IP addresses 10.x.x.x are just like 192.168.x.x addresses and cannot be routed
to external networks.

Thanks very much to all for your help. We found an error on router A’s config. The packets now arrive to Linux but are being dropped.

Here’s what I’m doing:

  ping 192.168.10.140 [from 192.168.5.253 (Server A)]

And this is what’s being logged on /var/log/firewall:

  Nov  9 16:27:48 psuse kernel: [666188.814700] SFW2-FWDext-DROP-DEFLT IN=eth0 OUT=eth1 SRC=192.168.5.253 DST=192.168.10.140 LEN=60 TOS=0x00 PREC=0x00 TTL=125 ID=27729 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=123

Can someone give me a clue about what could be wrong?
Tried this on /etc/sysconfig/SuSEfirewall2 with no luck:
FW_TRUSTED_NETS=“192.168.5.0/24,icmp 192.168.5.0/24,tcp 192.168.5.0/24,udp”

Could the probem lie on the http://www.maisqi.com/routes.txt?

First check if You have routing enabled on openSUSE. This command will tell You whether or not routing for ipv4 is enabled :

grzes@opensuse:~> cat /proc/sys/net/ipv4/ip_forward
0

0 = routing diabled
1 = routing enabled

or simply open YaST->/etc/sysconfig editor->search for ip_forward
SUSE Paste

Best regards,
Greg

Hi, Greg. It’s enabled – cat /proc/sys/net/ipv4/ip_forward prints “1”.
Any more ideas? Thanks.

On 2011-11-09 17:56, fmart8 wrote:

> Nov 9 16:27:48 psuse kernel: [666188.814700]
> SFW2-FWDext-DROP-DEFLT IN=eth0 OUT=eth1 SRC=192.168.5.253
> DST=192.168.10.140 LEN=60 TOS=0x00 PREC=0x00 TTL=125 ID=27729 PROTO=ICMP
> TYPE=8 CODE=0 ID=1 SEQ=123

Try

FW_ALLOW_PING_FW=“yes”
FW_ALLOW_PING_EXT=“yes”
FW_ALLOW_PING_DMZ=“yes”


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

Hello robin_listas. Thanks for responding.
Unfortunately, I had no luck.

FW_ALLOW_PING_FW
was empty, but defaults to “no”;

FW_ALLOW_PING_EXT
Changed to “yes” as suggested,

FW_ALLOW_PING_DMZ=“yes”
Changed to “yes” as suggested,

Still doesn’t work. I also checked if Server B’s firewall (192.198.10.140) was blocking ICMP but it turned out that it (the firewall) was disabled.

You can check the Linux’s firewall config. All help is very much appreciated. Thanks.

Try with firewall disabled on Linux server or if that’s not possible check which interfaces on openSUSE are connected where. From the configuration file You’ve pasted I see eth0 is in external zone and eth1 is internal. Which one of these interfaces is pointing towards router B ? Is router B a firewall as well ? If yes change both eth0 and eth1 to be in internal zone and this should just work.

Best regards,
Greg

Greg,
Isn’t the firewall responsible for passing packets between interfaces? If that’s the case, the packets should never pass with the firewall down.
Anyway, I disabled it but didn’t work.

eth0 links to Router B (external) and eth1 links to the internal network. Router B is a Dreytek router, in VPN mode.

Thanks for your help.

It depends on the nomenclature. Usually routing is responsible for passing packets between interfaces :slight_smile: firewall or (iptables) is for filtering out the packets You don’t need and some other tricks like NAT.

Did You try firewall enabled and both interfaces in internal zone ?

Best regards,
Greg

Hello, Greg. Please forgive me for taking so long to respond. In the meanwhile we tried almost everything we think of.

I can’t put all the interfaces on the internal zone because eth0 links to Router B, which is both an end point of the VPN and a link to the Internet. It seems to me that this would open an highway from the Internet to the internal network? Or am I totally wrong?

We get it to work though. We have set FW_FORWARD to 192.168.5.0/24,192.168.10.0/24. What do you think about this solution?

Thanks.