Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a dual-homed machine (1 LAN, 1 DMZ) using static IPs on both, with routes configured so that packets coming in on the LAN IP use a LAN gateway and DMZ packets use a DMZ gateway. I am using tcpdump for debugging on the local machine.

When establishing a TCP connection with a source IP on the DMZ subnet, the handshake proceeds normally. When establishing a TCP connection with a source IP outside the DMZ subnet to the DMZ nic, the server never returns an ACK.

I have confirmed that the ACKs are not leaving via the other nic. I have confirmed that no rules are configured in iptables (primary suspect at this point). Routes look appropriate. SYN packets look normal. I have confirmed that the IP-to-nic mapping is correct (and consistent across boots).

This configuration was working normally. I moved the hardware and changed the LAN and DMZ IPs, and now I am having issues. I updated the new IPs in both /etc/network/interfaces and in the hosts file (DMZ only).

Where else should I look to see where the traffic is being blocked?

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
10.0.0.0        0.0.0.0         255.255.255.0   U         0 0          0 eth2
10.10.0.0       10.10.0.1       255.255.255.0   UG        0 0          0 eth1
10.10.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 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth1
0.0.0.0         10.0.0.1        0.0.0.0         UG        0 0          0 eth2

(eth0 is unconfigured, 10.10.0.0/24 = DMZ, 10.0.0.0/24 = LAN)

share|improve this question
    
How have you configured your system to have multiple gateways? Are you using policy routing with iproute2? Can you post your route table(s)? Also, is rp_filter enabled? –  Zoredache Jan 26 '11 at 1:36
    
Route table added to the original post. rp_filter is not enabled. I am not using iproute2. –  HikeOnPast Jan 26 '11 at 5:34
    
Somehow, rp_filter ended up turned on, despite being commented out in sysctl. I forced it off, but still no change. –  HikeOnPast Jan 26 '11 at 21:36
add comment

1 Answer

up vote 0 down vote accepted

I found the issue. I needed to add an explicit route for eth1 to properly route traffic to the WAN from the DMZ.

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
<WAN subnet>    10.10.0.1       255.255.255.0   UG    0      0        0 eth1
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 eth2
10.10.0.0       10.10.0.1       255.255.255.0   UG    0      0        0 eth1
10.10.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 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth1
0.0.0.0         10.0.0.1        0.0.0.0         UG    100    0        0 eth2
share|improve this answer
    
I've seen similar behaviour on a few Oracle Enterprise Linux boxes. You might want to double check on iproute2 - do a "ip rule show" and a "ip route show" and you might see something interesting. –  Shaun Dewberry Mar 8 '11 at 7:19
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.