IP forwarding to another network
Hi,
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 Code:
# Firewall configuration written by system-config-securitylevel Code:
route add -net 10.1.2.0 netmask 255.255.255.0 gw 172.29.38.98 Code:
# route Code:
# traceroute 10.1.2.101 Any suggestions are more then welcome. |
@ Reply
Hi lpwevers,
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. I hope that helps. |
Hi,
Thanks for the help. Quote:
Quote:
Quote:
|
@ Reply
Hi lpwevers,
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. |
Hi T3RM1NVT0R,
Thanks for all the help so far. Quote:
Quote:
Code:
+---------------+ Code:
# traceroute 10.1.2.101 |
Hi lpwevers,
Now I got a clear picture: 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. |
Quote:
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 Code:
# ping magnas01 Code:
# tcpdump -i eth1 So here's the routing table of the router: Code:
# route |
Quote:
don't worry about the 169-thingy, it's the APIPA (Automatic Private IP Addressing), 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. Hope it made it clear. --- sibe |
Quote:
|
Code:
+---------------+ 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. |
Quote:
Thanks again. Louis |
@ Reply
Hi Louis,
You're welcome. Am glad to hear that the router is now working the way it should :-) |
All times are GMT -5. The time now is 12:17 AM. |