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?
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.
> 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
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!
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?
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.
> 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
I think I’d be inclined to get some more data before trying to draw any
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.
On 11/02/2011 07:16 AM, nrickert wrote:
> fmart8;2399703 Wrote:
>> Well, I only mentioned that fruit ( ) 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.
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.
It depends on the nomenclature. Usually routing is responsible for passing packets between interfaces 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 ?
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?