medent
asked on
Ip forwarding "partially" working.
Hi,
I used a 2.6 linux (rh ES 4.3) server as a gateway between two networks. This was working fine for a couple weeks , then started having odd problems. It would gateway through a telnet session or a ping/traceroute, but other apps (ie. http) would not gateway through. The firewall is 100% turned off. Selinux is off.
Reboot does not fix.
I reloaded the OS, configured same as before (same static routes, etc) and it works again 100% .
I am perplexed and wondering what could have been the problem?
I used a 2.6 linux (rh ES 4.3) server as a gateway between two networks. This was working fine for a couple weeks , then started having odd problems. It would gateway through a telnet session or a ping/traceroute, but other apps (ie. http) would not gateway through. The firewall is 100% turned off. Selinux is off.
Reboot does not fix.
I reloaded the OS, configured same as before (same static routes, etc) and it works again 100% .
I am perplexed and wondering what could have been the problem?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
hmmm...a reasonable strategy is get two hosts on both sides working reliably, then add from there...
I'd say simplify the routing table -- do you have direct connected hosts on eth0 and eth1?
I wonder if the "intermittent" problem is caused by OTHER hosts misbehaving
(i.e. eating the wrong packets?)
If you can isolate the problem hosts with fewer machine, and gradually add complexity (checking things all the time).
The alternative is start tracing the ethernet and the host -- not sure what
ethereal on eth0 and eth1 will do...
Did you swap in another box where the misbehaving one is and observe correct behavior?
I'd say simplify the routing table -- do you have direct connected hosts on eth0 and eth1?
I wonder if the "intermittent" problem is caused by OTHER hosts misbehaving
(i.e. eating the wrong packets?)
If you can isolate the problem hosts with fewer machine, and gradually add complexity (checking things all the time).
The alternative is start tracing the ethernet and the host -- not sure what
ethereal on eth0 and eth1 will do...
Did you swap in another box where the misbehaving one is and observe correct behavior?
Hi the correct strategy afaik is as follows
External Net (WAN) <-------> Gateway Server <---------> Internal Network (LAN)
Now the two devices would be
eth0 ----> for trusted (Internal Zone)
and
eth1 ----> for un-trusted (External or Intenet Zone)
to access the external net from inside you will setup a routing table and packet forwarding
so that the LAN users can access resources outside the network. may things like ftp etc.
for http access you can setup a proxy server i.e squid
The firewall rules would be setup on ip tables so that we protect our internal network from outside world.
Here is a sample from my implementation
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
200.295.164.1 * 255.255.255.255 UH 0 0 0 ppp0
10.0.0.0 * 255.255.255.0 U 0 0 0 eth0
169.254.0.0 * 255.255.0.0 U 0 0 0 eth0
default 200.295.164.1 0.0.0.0 UG 0 0 0 ppp0
in your case there are several routes present. Could u explain if you really need all those routes?
Regards,
makhan
External Net (WAN) <-------> Gateway Server <---------> Internal Network (LAN)
Now the two devices would be
eth0 ----> for trusted (Internal Zone)
and
eth1 ----> for un-trusted (External or Intenet Zone)
to access the external net from inside you will setup a routing table and packet forwarding
so that the LAN users can access resources outside the network. may things like ftp etc.
for http access you can setup a proxy server i.e squid
The firewall rules would be setup on ip tables so that we protect our internal network from outside world.
Here is a sample from my implementation
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
200.295.164.1 * 255.255.255.255 UH 0 0 0 ppp0
10.0.0.0 * 255.255.255.0 U 0 0 0 eth0
169.254.0.0 * 255.255.0.0 U 0 0 0 eth0
default 200.295.164.1 0.0.0.0 UG 0 0 0 ppp0
in your case there are several routes present. Could u explain if you really need all those routes?
Regards,
makhan
I have something more to add here
the traffic is controlled as follows
for outbound traffic (LAN to outside workd) eth0 will forward all the WAN pacckets to eth1
for inbound traffic (outside workd to LAN) eth1 will forward all the WAN packgets to eth0
HTH
makhan
the traffic is controlled as follows
for outbound traffic (LAN to outside workd) eth0 will forward all the WAN pacckets to eth1
for inbound traffic (outside workd to LAN) eth1 will forward all the WAN packgets to eth0
HTH
makhan
Some more explanation
In the sample routing table that I posted.
we have ppp over ethernet so ppp0 is shown instead of eth1
regards,
makhan
In the sample routing table that I posted.
we have ppp over ethernet so ppp0 is shown instead of eth1
regards,
makhan
ASKER
It was after I reloaded the OS that things started working. And they are working fine now , my setup is fine and its the exact same as it was when it stopped working. I am trying to determine what files, etc could cause ip_forwarding/routing to not work 100%, for example to pass ping but not http (again no firewall involved). Nic driver? or some tmp file?
Keep in mind things were working 100% - then something became corrupt. I am trying to determine that something. (I am evaling the OS so unfotunately an OS reload fix is not satisfactory)
Keep in mind things were working 100% - then something became corrupt. I am trying to determine that something. (I am evaling the OS so unfotunately an OS reload fix is not satisfactory)
well, assuming the dates are valid, you could do a
find /etc -mtime <when things went kaffloey>
With linux/unix, you never have to reload the OS IF you can figure out what's wrong -- reloading is such a last ditch effort...
What may be reasonable if have a running system, and a "backup" system on the same disk -- normally run the "running" system -- and if/when it breaks, see what changed
with the "backup" system -- but maybe you won't have the problem again?
find /etc -mtime <when things went kaffloey>
With linux/unix, you never have to reload the OS IF you can figure out what's wrong -- reloading is such a last ditch effort...
What may be reasonable if have a running system, and a "backup" system on the same disk -- normally run the "running" system -- and if/when it breaks, see what changed
with the "backup" system -- but maybe you won't have the problem again?
No refund please.
Split the points.
medent had already solved the problem by reloading the O/S. The whole exercise was just academic (Post Mortem of a non-existent dead body) :).
Regards,
makhan
Split the points.
medent had already solved the problem by reloading the O/S. The whole exercise was just academic (Post Mortem of a non-existent dead body) :).
Regards,
makhan
ASKER
good
ASKER
[root@support fil]# ip addr
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:14:5e:28:2c:88 brd ff:ff:ff:ff:ff:ff
inet 194.0.0.130/24 brd 194.0.0.255 scope global eth0
inet6 fe80::214:5eff:fe28:2c88/6
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:14:5e:28:2c:89 brd ff:ff:ff:ff:ff:ff
inet 10.80.1.1/16 brd 10.80.255.255 scope global eth1
inet6 fe80::214:5eff:fe28:2c89/6
valid_lft forever preferred_lft forever
4: sit0: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
[root@support fil]# service iptables status
Firewall is stopped.
[root@support fil]# 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
[root@support fil]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.160.0 ccsras_10 255.255.255.0 UG 0 0 0 eth1
192.168.182.0 edxp 255.255.255.0 UG 0 0 0 eth0
192.168.183.0 andrewxp 255.255.255.0 UG 0 0 0 eth0
192.168.181.0 mattxp 255.255.255.0 UG 0 0 0 eth0
192.168.170.0 new_ccsras 255.255.255.0 UG 0 0 0 eth1
192.168.186.0 mikexp 255.255.255.0 UG 0 0 0 eth0
194.0.0.0 * 255.255.255.0 U 0 0 0 eth0
192.168.187.0 demoxxp 255.255.255.0 UG 0 0 0 eth0
192.168.184.0 patxp 255.255.255.0 UG 0 0 0 eth0
192.168.185.0 johnxp 255.255.255.0 UG 0 0 0 eth0
192.168.188.0 mclxp 255.255.255.0 UG 0 0 0 eth0
192.168.189.0 GCDEMO-XP 255.255.255.0 UG 0 0 0 eth0
10.80.0.0 * 255.255.0.0 U 0 0 0 eth1
169.254.0.0 * 255.255.0.0 U 0 0 0 eth1
default ccsproxy_10 0.0.0.0 UG 0 0 0 eth1