linux-admin.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* arp corrupted
@ 2007-10-22  9:18 Bobby
  2007-10-22 19:05 ` terry white
  2007-10-23 20:47 ` Doug Knight
  0 siblings, 2 replies; 3+ messages in thread
From: Bobby @ 2007-10-22  9:18 UTC (permalink / raw)
  To: linux-admin

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: arp corrupted
  2007-10-22  9:18 arp corrupted Bobby
@ 2007-10-22 19:05 ` terry white
  2007-10-23 20:47 ` Doug Knight
  1 sibling, 0 replies; 3+ messages in thread
From: terry white @ 2007-10-22 19:05 UTC (permalink / raw)
  To: linux-admin

... ciao:

: on "10-22-2007" "Bobby" writ:
: 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

   the machine doesn't require lo ? ...

-- 
... i'm a man, but i can change,
    if i have to , i guess ...


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: arp corrupted
  2007-10-22  9:18 arp corrupted Bobby
  2007-10-22 19:05 ` terry white
@ 2007-10-23 20:47 ` Doug Knight
  1 sibling, 0 replies; 3+ messages in thread
From: Doug Knight @ 2007-10-23 20:47 UTC (permalink / raw)
  To: Bobby; +Cc: linux-admin

Bobby,

A long question merits a long response.

I suspect that your client's gateway is 192.168.0.254, so your PREROUTING
rules will be screwing up any traffic that uses tcp ports 80, 25, 21, or
110.  You should specify the destination address ( -d 192.168.0.254 ) in
the reroute rules so that you are not changin ports in traffic destined
for the outside world.

Of course, I could be way off.  If you're still having problems, try the
following:

# List your current (not working) ARP cache with
ip neigh show

# Clear your arp cache
ip neigh flush all

# Try to find 192.168.1.254 on eth0
arping -c 1 -I eth0 192.168.1.254

# Try to find 192.168.0.11 on eth1
arping -c 1 -I eth1 192.168.0.11

# List your ARP cache again
ip neigh show

# Clear your arp cache again
ip neigh flush all

# Try to ping 192.168.1.254
ping -c 1 192.168.1.254

# Try to ping 192.168.0.11
ping -c 1 192.168.0.11

# List your ARP cache again
ip neigh show

As long as it keeps finding 192.168.0.11 on dev eth1 and
192.168.1.254 on eth0, there is nothing wrong with ARP on
your network.

Otherwise, do an `ip rule show', then `ip route show
table <table-name/number>' for local, main, default, and any
other routing tables listed.  This will provide more detailed
information than you are getting with netstat.  Post your
results, with commands and the information above, answer the
following questions, and we'll see if we can figure anything
else for you.

1) What distribution of linux are you running?

2) What version of the kernel are you running?

3) What were the commands you used to obtain the information you
   listed in your original post?

4) What were you doing when you generated the arp who-has request?

5) What are the MAC addresses for each of the interfaces?

6) What do corp.domain.com and dell11.domain.com resolve to?
   (simply not reversing addresses would be easier to work with)

Doug Knight

Bobby wrote:
> 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.
> 
> 

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2007-10-23 20:47 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-10-22  9:18 arp corrupted Bobby
2007-10-22 19:05 ` terry white
2007-10-23 20:47 ` Doug Knight

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).