arp corrupted
am 22.10.2007 11:18:19 von bobby
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
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: arp corrupted
am 22.10.2007 21:05:05 von terry white
.... 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 ...
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: arp corrupted
am 23.10.2007 22:47:16 von Doug Knight
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 ' 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.
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html