Ip forwarding "partially" working.

Yes ip_forward is and was on. Keep in mind it was partially working - it would pass some traffic but not all. Here is the output of it's current working state (i do not have the status of the failing os).

[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/64 scope link
       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/64 scope link
       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

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?

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

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

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

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)  

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?

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