Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I'm facing a challenge in setting up a simple routing between 2 networks. The situation is as follows.
We're using 2 networks, 1 that handles all the office traffic and 1 that is used for storage traffic to the NAS. I'm trying to setup a simple router that will forward requests from the office LAN to the storage one, so people can access the NAS interface on the storage LAN.
So, I have a CentOS 5.5 box, connected to both networks that should handle this job. The office LAN is 172.29.38.0/24 and the storage LAN 10.1.2.0/24. IP adrresses of the linux box are 172.29.38.98 (eth0) and 10.1.2.98 (eth1).
First I started by enabling IP-forwarding in the kernel:
Code:
# cat /proc/sys/net/ipv4/ip_forward
1
Below is a copy of the iptables in use:
Code:
# Firewall configuration written by system-config-securitylevel
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
# Allow forwarding to storage LAN
-A FORWARD -j ACCEPT --in-interface eth0 --out-interface eth1
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# SSH
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
# HTTP Server
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
# Nagios
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 5666 -j ACCEPT
# Amanda backup
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 10080 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 10080 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 10082 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 10083 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT
Then, on the client side, I added a route to use the new router:
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
172.29.38.0 * 255.255.255.0 U 2 0 0 eth1
10.1.2.0 172.29.38.98 255.255.255.0 UG 0 0 0 eth1
loopback * 255.0.0.0 U 0 0 0 lo
default 172.29.38.800 0.0.0.0 UG 0 0 0 eth1
Unfortunately I cannot ping or in any other way access anything on the storate LAN from the office. According to traceroute, my route on the client machine should be working:
Code:
# traceroute 10.1.2.101
traceroute to 10.1.2.101 (10.1.2.101), 30 hops max, 40 byte packets using UDP
1 magsvl98 (172.29.38.98) 2.406 ms 3.007 ms 4.066 ms
2 * * *
3 * * *
It just never seems to get to the machine on the other side. I've verified that I can access both networks from the router and I can ping the router from my client.
Just to paraphrase you, you are trying to make the communication between the office network and the NAS using a CentOS system that will be acting as a router. For that you have put two ethernet cards on the CentOS system with 10.1.2.0/24 and 172.29.38.0/24 network. As I can see you are using firewall.
Now this is what I have done in my test environment to test this and was able to ping successfully. I also configured the firewall rules same as you, I did some tweaking on the networking part.
1. Configured one of my Redhat system with two nic cards giving them IPs 172.29.38.1 and 10.2.1.1 respectively. Using this server as the router. Firewall configuratiion same as you did.
2. Configured other machine (lets assume my office machine) with the IP 172.29.38.98, Subnet Mask: 255.255.255.0 Default gateway: 172.29.38.1
3. Configured other machine (lets assume my NAS) with the IP 10.1.2.98, Subnet Mask: 255.255.255.0 Default gateway: 10.1.2.1
Tried to ping 10.1.2.1 from 10.1.2.98 worked fine, tried to ping 10.1.2.1 from 172.29.38.98 worked fine.
Tried to ping 172.29.38.1 from 172.29.38.98 worked fine, tried to ping 10.1.2.1 from 10.1.2.98 worked fine.
Tried to ping 10.1.2.98 from 172.29.38.98 and it worked fine.
The output of the route that you showed is from the client side. I am not sure why there is need to define route in the client to use the router when the client can use the default gateway to reach the router. Unless you are using different subnet IP.
Even if you are using DHCP to distribute the IPs you can have the DHCP to assign the default gateway information to the client and in this case the default gateway for lets say office network will be the IP of router's interface.
Just to paraphrase you, you are trying to make the communication between the office network and the NAS using a CentOS system that will be acting as a router. For that you have put two ethernet cards on the CentOS system with 10.1.2.0/24 and 172.29.38.0/24 network. As I can see you are using firewall.
That is correct.
Quote:
1. Configured one of my Redhat system with two nic cards giving them IPs 172.29.38.1 and 10.2.1.1 respectively. Using this server as the router. Firewall configuratiion same as you did.
2. Configured other machine (lets assume my office machine) with the IP 172.29.38.98, Subnet Mask: 255.255.255.0 Default gateway: 172.29.38.1
3. Configured other machine (lets assume my NAS) with the IP 10.1.2.98, Subnet Mask: 255.255.255.0 Default gateway: 10.1.2.1
Tried to ping 10.1.2.1 from 10.1.2.98 worked fine, tried to ping 10.1.2.1 from 172.29.38.98 worked fine.
Tried to ping 172.29.38.1 from 172.29.38.98 worked fine, tried to ping 10.1.2.1 from 10.1.2.98 worked fine.
Tried to ping 10.1.2.98 from 172.29.38.98 and it worked fine.
The output of the route that you showed is from the client side. I am not sure why there is need to define route in the client to use the router when the client can use the default gateway to reach the router. Unless you are using different subnet IP.
Ah, that's where the difference resides. My machine with the 172.29.38.98 address is not the default router. It's only a router for the 10.1.2.0 network. There's another router in the network that acts as the default gateway. That one is a MS ISA server and they won't let me touch that for various reasons. That is why I set the rule on the client side for the 10.1.2.0/24 network. Was my assumtion that a static route would take precedence over the default GW perhaps incorrect? (If so, that explains the lot, then I'll just have to find a way around that).
Quote:
Even if you are using DHCP to distribute the IPs you can have the DHCP to assign the default gateway information to the client and in this case the default gateway for lets say office network will be the IP of router's interface.
I hope that helps.
It does help. I'll now go and see if I can figure out if it's indeed the order of rules that's bugging me (and if so, if there's a way around).
I just saw your routing table more closely what is 800 in the last line (172.29.38.800):
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
172.29.38.0 * 255.255.255.0 U 2 0 0 eth1
10.1.2.0 172.29.38.98 255.255.255.0 UG 0 0 0 eth1
loopback * 255.0.0.0 U 0 0 0 lo
default 172.29.38.800 0.0.0.0 UG 0 0 0 eth1
Also I would say default gateway is also a static route with 0.0.0.0 so it doesn't matter. The only reason default gateway will take precedence if it is directly connected to the systems and the static route defined is not.
I got a little bit confused when you said that 172.29.38.98 is not your default route it is just a router to 10.2.1.0 network.
Thats makes the environment as 10.2.1.0 is a network which is connected to two routers, one is 172.29.38.98 and another is MS ISA server acting as a router. The only reason that I can think of why 10.2.1.0 network is not forwarding packets to 172.29.38.0 network because MS ISA Server is directly connected to them and is a default route for forwarding the packets. As I mentioned before directly connected routes always have precedence over static routes/default route/dynamically discovered routes.
I just saw your routing table more closely what is 800 in the last line (172.29.38.800):
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
172.29.38.0 * 255.255.255.0 U 2 0 0 eth1
10.1.2.0 172.29.38.98 255.255.255.0 UG 0 0 0 eth1
loopback * 255.0.0.0 U 0 0 0 lo
default 172.29.38.800 0.0.0.0 UG 0 0 0 eth1
I guess I accidently overtyped something there. Should be 200. I just double-checked and it is indeed 200. Sorry about the confusion.
Quote:
Also I would say default gateway is also a static route with 0.0.0.0 so it doesn't matter. The only reason default gateway will take precedence if it is directly connected to the systems and the static route defined is not.
I got a little bit confused when you said that 172.29.38.98 is not your default route it is just a router to 10.2.1.0 network.
Thats makes the environment as 10.2.1.0 is a network which is connected to two routers, one is 172.29.38.98 and another is MS ISA server acting as a router. The only reason that I can think of why 10.2.1.0 network is not forwarding packets to 172.29.38.0 network because MS ISA Server is directly connected to them and is a default route for forwarding the packets. As I mentioned before directly connected routes always have precedence over static routes/default route/dynamically discovered routes.
Let me try to clarify the setup a bit more. The setup is something like the drawing below. The client is connected to both the gateways, as they're both on the same LAN. All internet traffic should be routed through the ISA server. All traffic for the 10.1.2.0 LAN should go through the CentOS box. There's no direct connection between the 10.1.2.0 and the 172.29.38.0 networks.
You are trying to establish a communication between the client machine and 10.2.1.0 network.
As I can see from the diagram client machines are connected to MS ISA server and 172.29.38.98 router. And as you said for 172.29.38.98 uses 172.29.38.200 as the default GW which mean if 172.29.38.98 router unable to identify where to send the packet then it will route it to default gateway.
Here is my question, did you set a static route to forward the packet received from client to forward to 10.2.1.0 network. Also I would like to see the routing table of 172.29.38.98 router.
As from the tracert command I can see that from the client machine packets are reaching till 172.29.38.98 router but not going through for which the only reason I can think of is that 172.29.38.98 router does not know where to forward the packet received from the client. Please check the routing table on 172.29.38.98 router as well the communication between 172.29.38.98 router and 10.2.1.0 network.
Just a point may not be much useful but just want to bring to your notice is that I can see latency in the output of tracert command, with 1 hop count reply should be less than 1 ms or equal to 1 ms.
You are trying to establish a communication between the client machine and 10.2.1.0 network.
As I can see from the diagram client machines are connected to MS ISA server and 172.29.38.98 router. And as you said for 172.29.38.98 uses 172.29.38.200 as the default GW which mean if 172.29.38.98 router unable to identify where to send the packet then it will route it to default gateway.
Here is my question, did you set a static route to forward the packet received from client to forward to 10.2.1.0 network. Also I would like to see the routing table of 172.29.38.98 router.
As from the tracert command I can see that from the client machine packets are reaching till 172.29.38.98 router but not going through for which the only reason I can think of is that 172.29.38.98 router does not know where to forward the packet received from the client. Please check the routing table on 172.29.38.98 router as well the communication between 172.29.38.98 router and 10.2.1.0 network.
Just a point may not be much useful but just want to bring to your notice is that I can see latency in the output of tracert command, with 1 hop count reply should be less than 1 ms or equal to 1 ms.
Hi T3RM1NVT0R,
Thanks for all the help so far. No I did not add a static route on the 172.29.38.98 router. By your suggestion I tried something like this.
Code:
route add -host 10.1.2.101 gw 172.29.38.98
Now if I try to ping the host I get back something like this:
Code:
# ping magnas01
PING magnas01 (10.1.2.101) 56(84) bytes of data.
From magsvl98 (172.29.38.98): icmp_seq=1 Redirect Host(New nexthop: magnas01 (10.1.2.101))
From magsvl98 (172.29.38.98): icmp_seq=2 Redirect Host(New nexthop: magnas01 (10.1.2.101))
From magsvl98 (172.29.38.98): icmp_seq=3 Redirect Host(New nexthop: magnas01 (10.1.2.101))
Removing that route again, I can see from a tcpdump on eth1 that the packets are actually forwarded to the target machine:
Code:
# tcpdump -i eth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
13:25:36.322127 IP 172.29.38.41 > magnas01: ICMP echo request, id 26402, seq 40, length 64
13:25:37.326621 IP 172.29.38.41 > magnas01: ICMP echo request, id 26402, seq 41, length 64
13:25:38.334666 IP 172.29.38.41 > magnas01: ICMP echo request, id 26402, seq 42, length 64
13:25:39.223922 arp who-has 10.1.2.1 tell 10.1.2.98
13:25:39.224419 arp reply 10.1.2.1 is-at bc:ae:c5:27:0f:64 (oui Unknown)
13:25:39.224425 IP 10.1.2.98 > 10.1.2.1: ICMP echo request, id 44086, seq 1, length 64
13:25:39.224727 IP 10.1.2.1 > 10.1.2.98: ICMP echo reply, id 44086, seq 1, length 64
13:25:39.355715 IP 172.29.38.41 > magnas01: ICMP echo request, id 26402, seq 43, length 64
13:25:40.216213 IP 10.1.2.98 > 10.1.2.1: ICMP echo request, id 44086, seq 2, length 64
13:25:40.216589 IP 10.1.2.1 > 10.1.2.98: ICMP echo reply, id 44086, seq 2, length 64
13:25:40.236436 IP 10.1.2.98.46333 > 10.1.2.5.ssh: S 59052039:59052039(0) win 5840 <mss 1460,sackOK,timestamp 368113868 0,nop,wscale 7>
13:25:40.236536 IP 10.1.2.5.ssh > 10.1.2.98.46333: S 2333143019:2333143019(0) ack 59052040 win 5792 <mss 1460,sackOK,timestamp 155414216 368113868,nop,wscale 6>
13:25:40.236556 IP 10.1.2.98.46333 > 10.1.2.5.ssh: . ack 1 win 46 <nop,nop,timestamp 368113868 155414216>
13:25:40.248131 IP 10.1.2.5.ssh > 10.1.2.98.46333: P 1:21(20) ack 1 win 91 <nop,nop,timestamp 155414218 368113868>
13:25:40.248393 IP 10.1.2.98.46333 > 10.1.2.5.ssh: . ack 21 win 46 <nop,nop,timestamp 368113872 155414218>
13:25:40.248740 IP 10.1.2.98.46333 > 10.1.2.5.ssh: P 1:21(20) ack 21 win 46 <nop,nop,timestamp 368113872 155414218>
13:25:40.250140 IP 10.1.2.5.ssh > 10.1.2.98.46333: . ack 21 win 91 <nop,nop,timestamp 155414218 368113872>
13:25:40.250163 IP 10.1.2.98.46333 > 10.1.2.5.ssh: P 21:733(712) ack 21 win 46 <nop,nop,timestamp 368113872 155414218>
13:25:40.250172 IP 10.1.2.5.ssh > 10.1.2.98.46333: P 21:725(704) ack 21 win 91 <nop,nop,timestamp 155414218 368113872>
13:25:40.288062 IP 10.1.2.98.46333 > 10.1.2.5.ssh: . ack 725 win 57 <nop,nop,timestamp 368113882 155414218>
13:25:40.288127 IP 10.1.2.5.ssh > 10.1.2.98.46333: . ack 733 win 113 <nop,nop,timestamp 155414222 368113872>
13:25:40.288139 IP 10.1.2.98.46333 > 10.1.2.5.ssh: P 733:757(24) ack 725 win 57 <nop,nop,timestamp 368113882 155414222>
13:25:40.288244 IP 10.1.2.5.ssh > 10.1.2.98.46333: . ack 757 win 113 <nop,nop,timestamp 155414222 368113882>
13:25:40.291862 IP 10.1.2.5.ssh > 10.1.2.98.46333: P 725:877(152) ack 757 win 113 <nop,nop,timestamp 155414222 368113882>
13:25:40.291883 IP 10.1.2.98.46333 > 10.1.2.5.ssh: . ack 877 win 68 <nop,nop,timestamp 368113882 155414222>
13:25:40.292941 IP 10.1.2.98.46333 > 10.1.2.5.ssh: P 757:901(144) ack 877 win 68 <nop,nop,timestamp 368113882 155414222>
13:25:40.304019 IP 10.1.2.5.ssh > 10.1.2.98.46333: P 877:1597(720) ack 901 win 135 <nop,nop,timestamp 155414223 368113882>
13:25:40.305114 IP 10.1.2.98.46333 > 10.1.2.5.ssh: P 901:917(16) ack 1597 win 79 <nop,nop,timestamp 368113886 155414223>
13:25:40.338085 IP 10.1.2.5.ssh > 10.1.2.98.46333: . ack 917 win 135 <nop,nop,timestamp 155414227 368113886>
13:25:40.338109 IP 10.1.2.98.46333 > 10.1.2.5.ssh: P 917:965(48) ack 1597 win 79 <nop,nop,timestamp 368113894 155414227>
13:25:40.338393 IP 10.1.2.5.ssh > 10.1.2.98.46333: . ack 965 win 135 <nop,nop,timestamp 155414227 368113894>
13:25:40.338405 IP 10.1.2.5.ssh > 10.1.2.98.46333: P 1597:1645(48) ack 965 win 135 <nop,nop,timestamp 155414227 368113894>
13:25:40.338787 IP 10.1.2.98.46333 > 10.1.2.5.ssh: P 965:1029(64) ack 1645 win 79 <nop,nop,timestamp 368113894 155414227>
13:25:40.339126 IP 10.1.2.5.ssh > 10.1.2.98.46333: P 1645:1725(80) ack 1029 win 135 <nop,nop,timestamp 155414227 368113894>
13:25:40.350653 IP 172.29.38.41 > magnas01: ICMP echo request, id 26402, seq 44, length 64
13:25:40.375997 IP 10.1.2.98.46333 > 10.1.2.5.ssh: . ack 1725 win 79 <nop,nop,timestamp 368113904 155414227>
13:25:40.452397 IP 10.1.2.98.46333 > 10.1.2.5.ssh: P 1029:1557(528) ack 1725 win 79 <nop,nop,timestamp 368113923 155414227>
13:25:40.453130 IP 10.1.2.5.ssh > 10.1.2.98.46333: P 1725:2205(480) ack 1557 win 158 <nop,nop,timestamp 155414238 368113923>
13:25:40.453159 IP 10.1.2.98.46333 > 10.1.2.5.ssh: . ack 2205 win 91 <nop,nop,timestamp 368113923 155414238>
13:25:40.454073 IP 10.1.2.98.46333 > 10.1.2.5.ssh: P 1557:2133(576) ack 2205 win 91 <nop,nop,timestamp 368113923 155414238>
13:25:40.456406 IP 10.1.2.5.ssh > 10.1.2.98.46333: P 2205:2237(32) ack 2133 win 180 <nop,nop,timestamp 155414238 368113923>
13:25:40.456762 IP 10.1.2.98.46333 > 10.1.2.5.ssh: P 2133:2197(64) ack 2237 win 91 <nop,nop,timestamp 368113924 155414238>
13:25:40.458423 IP 10.1.2.5.ssh > 10.1.2.98.46333: P 2237:2285(48) ack 2197 win 180 <nop,nop,timestamp 155414239 368113924>
13:25:40.458840 IP 10.1.2.98.46333 > 10.1.2.5.ssh: P 2197:2437(240) ack 2285 win 91 <nop,nop,timestamp 368113924 155414239>
13:25:40.465278 IP 10.1.2.5.ssh > 10.1.2.98.46333: P 2285:2333(48) ack 2437 win 202 <nop,nop,timestamp 155414239 368113924>
13:25:40.465544 IP 10.1.2.98.46333 > 10.1.2.5.ssh: P 2437:2469(32) ack 2333 win 91 <nop,nop,timestamp 368113926 155414239>
13:25:40.484347 IP 10.1.2.5.ssh > 10.1.2.98.46333: P 2333:2413(80) ack 2469 win 202 <nop,nop,timestamp 155414241 368113926>
13:25:40.523990 IP 10.1.2.98.46333 > 10.1.2.5.ssh: . ack 2413 win 91 <nop,nop,timestamp 368113941 155414241>
13:25:40.524091 IP 10.1.2.5.ssh > 10.1.2.98.46333: P 2413:2541(128) ack 2469 win 202 <nop,nop,timestamp 155414245 368113941>
13:25:40.524110 IP 10.1.2.98.46333 > 10.1.2.5.ssh: . ack 2541 win 102 <nop,nop,timestamp 368113941 155414245>
13:25:40.524611 IP 10.1.2.98.46333 > 10.1.2.5.ssh: P 2469:2501(32) ack 2541 win 102 <nop,nop,timestamp 368113941 155414245>
13:25:40.524819 IP 10.1.2.98.46333 > 10.1.2.5.ssh: F 2501:2501(0) ack 2541 win 102 <nop,nop,timestamp 368113941 155414245>
13:25:40.526629 IP 10.1.2.5.ssh > 10.1.2.98.46333: F 2541:2541(0) ack 2502 win 202 <nop,nop,timestamp 155414245 368113941>
13:25:40.526651 IP 10.1.2.98.46333 > 10.1.2.5.ssh: . ack 2542 win 102 <nop,nop,timestamp 368113941 155414245>
13:25:41.216058 IP 10.1.2.98 > 10.1.2.1: ICMP echo request, id 44086, seq 3, length 64
13:25:41.216411 IP 10.1.2.1 > 10.1.2.98: ICMP echo reply, id 44086, seq 3, length 64
13:25:41.359089 IP 172.29.38.41 > magnas01: ICMP echo request, id 26402, seq 45, length 64
13:25:42.216124 IP 10.1.2.98 > 10.1.2.1: ICMP echo request, id 44086, seq 4, length 64
13:25:42.216510 IP 10.1.2.1 > 10.1.2.98: ICMP echo reply, id 44086, seq 4, length 64
13:25:42.367087 IP 172.29.38.41 > magnas01: ICMP echo request, id 26402, seq 46, length 64
13:25:43.216183 IP 10.1.2.98 > 10.1.2.1: ICMP echo request, id 44086, seq 5, length 64
13:25:43.216557 IP 10.1.2.1 > 10.1.2.98: ICMP echo reply, id 44086, seq 5, length 64
13:25:43.375590 IP 172.29.38.41 > magnas01: ICMP echo request, id 26402, seq 47, length 64
13:25:44.218313 arp who-has 10.1.2.98 tell 10.1.2.1
13:25:44.218325 arp reply 10.1.2.98 is-at 92:fe:8f:59:d9:2f (oui Unknown)
13:25:44.383124 IP 172.29.38.41 > magnas01: ICMP echo request, id 26402, seq 48, length 64
13:25:45.391177 IP 172.29.38.41 > magnas01: ICMP echo request, id 26402, seq 49, length 64
13:25:46.399258 IP 172.29.38.41 > magnas01: ICMP echo request, id 26402, seq 50, length 64
13:25:47.407377 IP 172.29.38.41 > magnas01: ICMP echo request, id 26402, seq 51, length 64
69 packets captured
69 packets received by filter
0 packets dropped by kernel
Towards the bottom of the dump I actually do have a feeling that the router (magsvl98) is actually forwarding the packtets to the target machine (magnas01; 10.1.2.101). Indeed, the client I'm trying from is 172.29.38.41.
So here's the routing table of the router:
Code:
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
172.29.38.0 * 255.255.255.0 U 0 0 0 eth0
10.1.2.0 * 255.255.255.0 U 0 0 0 eth1
169.254.0.0 * 255.255.0.0 U 0 0 0 eth1
default 172.29.38.200 0.0.0.0 UG 0 0 0 eth0
The only strange thing I see on this one is the 169.254.0.0/16 network. Don't have a clue where that comes from. (I checked some more machines in the same net, and they all have it).
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
172.29.38.0 * 255.255.255.0 U 0 0 0 eth0
10.1.2.0 * 255.255.255.0 U 0 0 0 eth1
169.254.0.0 * 255.255.0.0 U 0 0 0 eth1
default 172.29.38.200 0.0.0.0 UG 0 0 0 eth0
The only strange thing I see on this one is the 169.254.0.0/16 network. Don't have a clue where that comes from. (I checked some more machines in the same net, and they all have it).
Hi,
don't worry about the 169-thingy, it's the APIPA (Automatic Private IPAddressing),
APIPA enables DHCP clients to automatically self-configure an IP address and subnet mask when it cannot find a DHCP server. If the client is unable to find the information, it uses APIPA to configure itself with an IP within the range of 169.254.0.1 - 169.254.255.254, applying a default class B subnet mask of 255.255.0.0, and going into a "limited connectivity" status that sometimes poped-up over a ms windows taskbar.
Actually, IANA has reserved this specific range of addresses, especially for Microsoft. As a result, APIPA provides an address that is guaranteed not to conflict with any routable addresses.
As per the above diagram 172.29.38.98 is the router between the client network which is 172.29.38.0 and 10.1.2.0 network. If I am not wrong you have taken this trace from 172.29.38.98 machine as I can see packets from both 172.29.38.98 network as well as from 10.1.2.0 network. Also it appears that eth0 on this machine (172.29.38.98) is interface for 172.29.38.0 network and eth1 is interface to 10.1.2.0 network.
From the trace as I can see I still doubt that there is a communication between client and 10.1.2.0 network.
If you see at the very beginning of the trace 172.29.38.41 (which I assume is one of the client machine) sending ping request to magnas01 (10.1.2.101) but is unable to get a ICMP reply. See below:
3:25:36.322127 IP 172.29.38.41 > magnas01: ICMP echo request, id 26402, seq 40, length 64
13:25:37.326621 IP 172.29.38.41 > magnas01: ICMP echo request, id 26402, seq 41, length 64
13:25:38.334666 IP 172.29.38.41 > magnas01: ICMP echo request, id 26402, seq 42, length 64
Also if you scroll down a bit you will see 10.1.2.98 sending an ICMP request to 10.1.2.1 which are in the same network and it is getting an immediate response from 10.1.2.1
13:25:39.224425 IP 10.1.2.98 > 10.1.2.1: ICMP echo request, id 44086, seq 1, length 64
13:25:39.224727 IP 10.1.2.1 > 10.1.2.98: ICMP echo reply, id 44086, seq 1, length 64
Here I am assuming the things because I am not sure on which machine tcpdump has been executed but from the trace it looks like it has been executed on 172.29.38.98.
As you mentioned in the post you have removed the static route that you have added for testing purpose and then took a trace. Can you please add up that static route again and then take a trace on 172.29.38.98 machine.
If I am getting it correctly the current situation is 172.29.38.0 network machines can ping 172.29.38.98 router on eth0 and 10.1.2.0 machines can also ping 172.29.38.98 router on eth1 having ip 10.1.2.98. Also 172.29.38.0 network can ping the eth1 interface on the router which is (10.1.2.98) and vice-versa but there is not communication between these two networks 172.29.38.0 and 10.1.2.98 so it definitely appears to be a routing issue on 172.29.38.98 router because it is accepting packets on eth0 172.29.38.98 and even for eth1 but not able to forward it to network 10.1.2.0.
Let me know if I am understanding the situation correctly and then we can take it from there.
PS:-
Here I have got a suggestion in advance assuming whatever I understood above is correct. On this machine 172.29.38.98 if eth1 is 10.1.2.98 then add a static route entry route add -host 10.1.2.101 gw 10.1.2.98 and see if that works.
Here I have got a suggestion in advance assuming whatever I understood above is correct. On this machine 172.29.38.98 if eth1 is 10.1.2.98 then add a static route entry route add -host 10.1.2.101 gw 10.1.2.98 and see if that works.
You assumed correct. And many, many thanks. I got it working now. Needed a route add -net 10.1.2.0/24 gw 10.1.2.98 on the 172.29.38.98 router. The router is now working as it should.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
