LinuxQuestions.org - Routing problems

- Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)

- - Routing problems (https://www.linuxquestions.org/questions/linux-networking-3/routing-problems-510912/)

Routing problems

Hi all.

EDIT: Every "/8" should be "/24", sorry!

I have a problem with routing, I think. Let me tell you about my setup first:

I have a Netgear WGR614v6 wired/wireless router between all my computers and the internet. This router (192.168.1.1) serves as a router, firewall and DHCP server for my first network (192.168.1.0/8). On IP address 192.168.1.5 I have a second router (Debian 3.1 Sarge) behind which is my second network, 192.168.2.0/8. 192.168.1.1 has a static route to 192.168.1.5 for all traffic to the 192.168.2.0/8 network. The Netgear router forwards port 80 to 192.168.1.5.

The clients (including the debian-router) on the 192.168.1.0/8 connects fine to the Internet. The clients on the 192.168.2.0/8 network can connect all the computers on the network.

Here's some consoledumps from the debian router:

Code:

tfault@debian-router:~$ /sbin/ifconfig ath0; /sbin/ifconfig eth0

ath0      Link encap:Ethernet  HWaddr 00:11:95:91:6C:4A  

          inet addr:192.168.1.5  Bcast:192.168.1.255  Mask:255.255.255.0

          inet6 addr: fe80::211:95ff:fe91:6c4a/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:608185 errors:0 dropped:0 overruns:0 frame:0

          TX packets:640557 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0 

          RX bytes:201509116 (192.1 MiB)  TX bytes:45116030 (43.0 MiB)



eth0      Link encap:Ethernet  HWaddr 00:02:A5:CF:20:A6  

          inet addr:192.168.2.1  Bcast:192.168.2.255  Mask:255.255.255.0

          inet6 addr: fe80::202:a5ff:fecf:20a6/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:37539 errors:0 dropped:0 overruns:0 frame:0

          TX packets:44154 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000 

          RX bytes:3811856 (3.6 MiB)  TX bytes:31275825 (29.8 MiB)

tfault@debian-router:~$ netstat -r

Kernel IP routing table

Destination    Gateway        Genmask        Flags  MSS Window  irtt Iface

192.168.2.0    *              255.255.255.0  U        0 0          0 eth0

192.168.1.0    *              255.255.255.0  U        0 0          0 ath0

default        192.168.1.1    0.0.0.0        UG        0 0          0 ath0

tfault@debian-router:~$ cat /proc/sys/net/ipv4/ip_forward 

1

tfault@debian-router:~$ sudo iptables -L

Chain INPUT (policy ACCEPT)

target    prot opt source              destination        



Chain FORWARD (policy ACCEPT)

target    prot opt source              destination        



Chain OUTPUT (policy ACCEPT)

target    prot opt source              destination

And here's some from a computer on the 192.168.2.0 network:

Code:

tfault@192.168.2-client:~$ /sbin/ifconfig eth0

eth0      Link encap:Ethernet  HWaddr 00:0C:76:E5:87:C4  

          inet addr:192.168.2.100  Bcast:192.168.2.255  Mask:255.255.255.0

          inet6 addr: fe80::20c:76ff:fee5:87c4/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:982101 errors:0 dropped:0 overruns:0 frame:0

          TX packets:1288334 errors:0 dropped:0 overruns:52 carrier:0

          collisions:0 txqueuelen:1000 

          RX bytes:479318452 (457.1 MiB)  TX bytes:1107810773 (1.0 GiB)

          Interrupt:193 Base address:0x2f00 

tfault@192.168.2-client:~$ netstat -r

Kernel IP routing table

Destination    Gateway        Genmask        Flags  MSS Window  irtt Iface

192.168.2.0    *              255.255.255.0  U        0 0          0 eth0

default        192.168.2.1    0.0.0.0        UG        0 0          0 eth0

Clients on the 192.168.1.0/8 network look similar to the one on the 192.168.2.0/8 network except the IPs and broadcast address is changed to the proper values.

Finaly, the problems. The clients on the 192.168.1.0/8 network cannot connect to the 192.168.2.0/8 network and the clients on the 192.168.2.0/8 network cannot connect to computers outside the entire network (that would be the internet). As I mentioned previously, I have forwarded port 80 on the netgear-router to the 192.168.1.5 IP, but I cannot connect to this port from the internet.

As far as I can see, the setup on the debian-router looks okay. Doesn't it? I think the netgear router is set up as it should be (btw, that interface royally sucks) but I am not completely sure. Anyone have some input as to what could be the solution?

your subnet isn't a /8, it is actually a /24...that confused me for a second.

Also, is 192.168.1.5/24 an http server? Why are you forwarding port 80 to it?

I am going to read your post a couple more times to see if I understand you setup better.

first of all 192.168.1.0/8 and 192.168.2.0/8 are the same network. You mean 192.168.1.0/24 and 192.168.2.0/24.
can you ping from your client to the first router? "ping 192.168.1.1" from the client in the 2.0 network? during the ping can you try a packet capture with tcpdump?
also what do you see pinging the internet from the debian router sourced from the 2.1 interface?
"ping -I 192.168.2.1 www.yahoo.com"

Whoops, sorry. The netmask of the two subnets is 255.255.255.0 which i though translated to /8. I'm so sorry!

I have a lot of servers on the debian-router (.1.5): Squid, DHCP for the .2.0 network and Apache2. I forward port 80 to .1.5 to server web pages to the internet.

I can ping the first router (both internal and external interfaces) from both networks. Also, I can ping computers on the .2.0 network from the .1.0 network. "ping -I 192.168.2.1 www.yahoo.com" gives a timeout, but isn't that expected as I tell 'ping' to use the .2.1 interface?

I will create a tcpdump later (it is too late now, must sleep). How verbose would you like it?

well by pinging from the 2.1 interface its like telling it that you are coming from the 2.0 network.
so you can ping the first router (1.1) from the 2.0 computers? your routing seems fine if this is the case. Maybe it just doesn't nat for addresses not on the 1.0 network.
Yes a tcpdump will help as long as we see the src and dst packets.

Could you check if you have the "ip_conntrack" module loaded on the debian-router?

I had once used my laptop to route desktop traffic to my wireless router. Even though the routes were correct and ip_forward was set, the traffic wasn't getting through until I loaded the ip_conntrack module, even though the laptop wasn't being used to NAT addresses.

"ping 192.168.1.1" from the .2.0 network works fine! Here's the tcpdump from 192.168.1.5 interface on the debian router:

Code:

14:49:55.524572 IP 192.168.2.100 > 192.168.1.1: icmp 64: echo request seq 1

14:49:55.525567 IP 192.168.1.1 > 192.168.2.100: icmp 64: echo reply seq 1

14:49:56.532478 IP 192.168.2.100 > 192.168.1.1: icmp 64: echo request seq 2

14:49:56.534100 IP 192.168.1.1 > 192.168.2.100: icmp 64: echo reply seq 2

14:49:57.588315 IP 192.168.2.100 > 192.168.1.1: icmp 64: echo request seq 3

14:49:57.589312 IP 192.168.1.1 > 192.168.2.100: icmp 64: echo reply seq 3

14:49:58.590862 IP 192.168.2.100 > 192.168.1.1: icmp 64: echo request seq 4

14:49:58.591858 IP 192.168.1.1 > 192.168.2.100: icmp 64: echo reply seq 4

14:49:59.594726 IP 192.168.2.100 > 192.168.1.1: icmp 64: echo request seq 5

14:49:59.595722 IP 192.168.1.1 > 192.168.2.100: icmp 64: echo reply seq 5

Here's a tcpdump from the same interface, but I ping a computer on the .2.0 network from the .1.0 network:

Code:

15:02:04.117753 IP 83.XX.XXX.XXX > 192.168.2.100: icmp 64: echo request seq 55034

15:02:04.118030 IP 192.168.2.100 > 83.XX.XXX.XXX: icmp 64: echo reply seq 55034

15:02:05.121767 IP 83.XX.XXX.XXX > 192.168.2.100: icmp 64: echo request seq 55035

15:02:05.122048 IP 192.168.2.100 > 83.XX.XXX.XXX: icmp 64: echo reply seq 55035

15:02:06.125784 IP 83.XX.XXX.XXX > 192.168.2.100: icmp 64: echo request seq 55036

15:02:06.126054 IP 192.168.2.100 > 83.XX.XXX.XXX: icmp 64: echo reply seq 55036

15:02:07.129784 IP 83.XX.XXX.XXX > 192.168.2.100: icmp 64: echo request seq 55037

15:02:07.130040 IP 192.168.2.100 > 83.XX.XXX.XXX: icmp 64: echo reply seq 55037

15:02:08.133914 IP 83.XX.XXX.XXX > 192.168.2.100: icmp 64: echo request seq 55038

15:02:08.134193 IP 192.168.2.100 > 83.XX.XXX.XXX: icmp 64: echo reply seq 55038

15:02:09.137783 IP 83.XX.XXX.XXX > 192.168.2.100: icmp 64: echo request seq 55039

15:02:09.138063 IP 192.168.2.100 > 83.XX.XXX.XXX: icmp 64: echo reply seq 55039

The 83.XX.XXX.XXX IP is my internet IP, the address of the external interface on the first router. That doesn't look right!

When I do "telnet 83.XX.XXX.XXX 80" from a client on the .2.0 network I get the following output from tcpdump (still on the same interface):

Code:

15:20:13.541009 IP 192.168.2.100.56285 > 83.XX.XXX.XXX.XX: S 3050318295:3050318295(0) win 5840 <mss 1460,sackOK,timestamp 62411280 0,nop,wscale 2>

15:20:13.541802 IP truncated-ip - 15300 bytes missing! 83.XX.XXX.XXX > 192.168.1.5: tcp

15:20:19.540041 IP 192.168.2.100.56285 > 83.XX.XXX.XXX.XX: S 3050318295:3050318295(0) win 5840 <mss 1460,sackOK,timestamp 62412780 0,nop,wscale 2>

15:20:19.540819 IP truncated-ip - 15300 bytes missing! 83.XX.XXX.XXX > 192.168.1.5: tcp

"truncated-ip", "15300 bytes missing!" that doesn't look good. What do they mean?

EDIT: After messing around with the W3 online HTML validator I noticed I was able to make connections from outside (the internet) the network, to the forwarded port 80. Alas, I still cannot get a connection through from inside the networks to the forwarded port.

Did YOU load the module "ip_conntrack" yet? Did YOU enable "IP forwarding"? Have YOU setup a Firewall? Have YOU checked the Firewall rules, are they correct for YOUR needs? If YOU disable Port 80, can YOU still ping the same directions as before, or in only one direction? Hope this helps. Also, some great reading...http://tldp.org/HOWTO/HOWTO-INDEX/howtos.html