CentOS - Oct 2007 - arp corrupted

Hi,

I've been trying to get a couple of routers up after h/w failure.

The border router is an OpenBSD firewall running NAT between the Internet and 
a DMZ like subnet, and in that a Linux antivirus server is running NAT to the 
LAN. 

When the client does a DNS query it reaches to the f/w where dns is running 
and is returned into the A/V server but never hits the 0.254 interface. 
(Shown by running tcpdump on each interface.)

(Internet)
	|
OpenBSD Firewall 
NAT 192.168.1.254
	|
192.168.1.253 eth0
Anti-Virus in "DMZ"
192.168.0.254 eth1
	|
192.168.0.11
Client on LAN

The routing table on the A/V server is:
 192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
 192.168.0.0     192.168.0.254   255.255.255.0   UG        0 0          0 eth1
 192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 eth1
 169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth1
 0.0.0.0         192.168.1.254   0.0.0.0         UG        0 0          0 eth0

Sitting on the A/V server one can reach the client without problem.

Arp shows:
 Address             HWtype  HWaddress           Flags Mask            Iface
 192.168.1.254        ether   00:20:78:0F:AC:31   C                     eth0

Unless I try to reach the client web server from the A/Vserver, then it fails 
and arp says:

 Address              HWtype  HWaddress           Flags Mask            Iface
 corp.domain.com          (incomplete)                              eth0
 dell11.domain.com  ether   00:06:29:AF:A3:67   C                 eth1
 192.168.1.254            ether   00:20:78:0F:AC:31   C                   eth0

One can also see the arp requests go out on eth 0 rather than eth1:

 arp who-has 192.168.0.10 tell 192.168.0.254

Pinging works well:

 PING 192.168.0.11 (192.168.0.11) 56(84) bytes of data.
 64 bytes from 192.168.0.11: icmp_seq=0 ttl=64 time=0.277 ms

Iptables on the A/V server says:

*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-port 9080
-A PREROUTING -i eth1 -p tcp -m tcp --dport 110 -j REDIRECT --to-port 9110
-A PREROUTING -i eth1 -p tcp -m tcp --dport 25 -j REDIRECT --to-port 9025
-A PREROUTING -i eth1 -p tcp -m tcp --dport 21 -j REDIRECT --to-port 9021
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:Firewall-INPUT - [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -j ACCEPT
COMMIT

It is supposed to route all outbound traffic through the various ports where 
the A/V s/w is listening.

ifconfig shows:

eth0      Link encap:Ethernet  HWaddr 00:0D:88:39:6A:F1
          inet addr:192.168.1.253  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::20d:88ff:fe39:6af1/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:77670 errors:0 dropped:0 overruns:0 frame:0
          TX packets:97635 errors:0 dropped:0 overruns:0 carrier:0
          collisions:523 txqueuelen:1000
          RX bytes:22858238 (21.7 MiB)  TX bytes:21513745 (20.5 MiB)
          Interrupt:11 Base address:0x2400

eth1      Link encap:Ethernet  HWaddr 00:50:FC:AC:52:4B
          inet addr:192.168.0.254  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::250:fcff:feac:524b/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:26676 errors:0 dropped:0 overruns:0 frame:0
          TX packets:20424 errors:0 dropped:0 overruns:1 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2747567 (2.6 MiB)  TX bytes:26324006 (25.1 MiB)
          Interrupt:7 Base address:0x2800

If NAT did not work I could see it having a problem. It appears to be happy 
routing icmp but not tcp. cat /proc/sys/net/ipv4/ip_forward shows 1 which it 
would have to anyway since the request goes out from the LAN.


-- 

Bobby

Bobby wrote:
> Unless I try to reach the client web server from the A/Vserver, then it
fails
> and arp says:
> 
>  Address              HWtype  HWaddress           Flags Mask           
Iface
>  corp.domain.com          (incomplete)                              eth0
>  dell11.domain.com  ether   00:06:29:AF:A3:67   C                 eth1
>  192.168.1.254            ether   00:20:78:0F:AC:31   C                  
eth0
> 
> One can also see the arp requests go out on eth 0 rather than eth1:
> 
>  arp who-has 192.168.0.10 tell 192.168.0.254
Put 

net.ipv4.conf.all.arp_filter = 1

into your /etc/sysctl.conf

and run (for the time being) 

sysctl -w net.ipv4.conf.all.arp_filter=1

Linux implements the weak host model, so packages are accepted on any
interface, *if* the traffic is directed at the host.

When arp is used, this model doesn't always work. That's why you should
use the sysctl setting above.

Cheers,

Ralph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.centos.org/pipermail/centos/attachments/20071021/b1bfbc05/attachment-0004.sig>

On Sunday 21 October 2007 13:26:35 Ralph Angenendt
wrote:
> sysctl -w net.ipv4.conf.all.arp_filter=1
That stops the AVserver from answering arp requests.

-- 

Bobby