0

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)

Improve this question
3
  • 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, 2011 at 1:36
  • Route table added to the original post. rp_filter is not enabled. I am not using iproute2.
    – HikeOnPast
    Jan 26, 2011 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, 2011 at 21:36

1 Answer 1

Reset to default
0

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
Improve this answer
1
  • 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, 2011 at 7:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .