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 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
Bobby wrote:
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.
Now that is *strange*.
Can you look with tcpdump what happens on the network?
tcpdump -i any arp
should do that.
Cheers,
Ralph
On Sunday 21 October 2007 14:11:15 Ralph Angenendt wrote:
Bobby wrote:
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.
Now that is *strange*.
Can you look with tcpdump what happens on the network?
tcpdump -i any arp
should do that.
Cheers,
Ralph
That's what I've been doing for a couple of days. The requests goes unanswered. I'm monitoring all the NICs and can follow it in real time.
I sniffed it to see if there were any clues but all is totally standard IP.
Bobby wrote:
On Sunday 21 October 2007 14:11:15 Ralph Angenendt wrote:
Can you look with tcpdump what happens on the network?
tcpdump -i any arp
should do that.
That's what I've been doing for a couple of days. The requests goes unanswered. I'm monitoring all the NICs and can follow it in real time.
I sniffed it to see if there were any clues but all is totally standard IP.
But through which interfaces did the arp requests arrive *before* turning on arp_filter and on which interfaces do they arrive *after* setting arp_filter?
If both cards are on the same switch and arp_filtering is turned off, any of the two interfaces will answer arp requests for both cards, as both requests go to an interface, which is local to the machine.
Turning on arp_filtering, each interface will only answer requests directed at that interface.
Can you send some sniffing output *before* and *after* changing the setting? Is there anything strange in dmesg?
Cheers,
Ralph
-
Bobby -
Ralph Angenendt