Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am trying to setup a captive web portal redirect on CentOS using the following configuration:

This configuration works for the first few packets, but then suddenly the destination port is corrupted in the response from the server. The packet trace looks like this:

Client: The host making the original web request. Server: Original destination for the request Portal: Captive portal server

This packet trace is taken from a place that can see both the client and portal traffic. Lines that start with c: are from the client side, and p: are from the portal side.

c: client:57877 -> server:80 [SYN]
p: client:1092 -> portal:80 [SYN]  NAT adjusted SYN
p: portal:80 -> client:1092 [SYN, ACK]
c: server:80 -> client:57877 [SYN, ACL] NAT reversed on the SYN/ACK
c: client:57877 -> server:80 [ACK]
c: client:57877 -> server:80 HTTP GET
p: client:1092 -> portal:80 [ACK]
p: client:1092 -> portal:80 HTTP GET
p: portal:80 -> client:1092 [ACK]
c: server:68 -> client:57877 [ACK]
          ^^ WTF?!?

At this point the connection is hosed. The client isn't expecting a packet on that port and sends a RST. The broken port number increments by 1 every time this connection is attempted (presumably it will work once 12 attempts from now). All retransmissions have the same broken port number on the response. I have no idea what could be causing this.

Is this a bug, or am I doing something wrong? This machine does have a somewhat unusual configuration. It is configured as a bridge. In order to only apply the NAT rule to packets going in a single direction, the packets are marked with an ebtables NAT rule first, and that mark is checked when the iptables NAT is applied.

This is on Enterprise Linux 6 with Kernel 2.6.32-279.5.2.el6.x86_64

The NAT rule is:

target     prot opt in     out     source               destination         
DNAT       tcp  --  ilb    any     anywhere             anywhere            multiport dports http,https mark match 0x8 to:<portal IP>

ilb is the bridge.

share|improve this question
Why are you running an out of date kernel? – Michael Hampton Jan 12 '14 at 19:48
Updating the kernel affects the security checking software on this machine. It's not impossible to update it, but it requires a lot of extra paperwork so I was hoping to avoid it, plus there is no guarantee that a newer kernel would change this behavior. – Jason Andresen Jan 13 '14 at 14:54
Additionally, Enterprise Linux is more or less locked to that kernel version. I have done the update to the latest offered kernel, but that is version 2.6.32-431. Worse, they make it difficult to build your own kernel. – Jason Andresen Jan 16 '14 at 16:21

Your Answer


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

Browse other questions tagged or ask your own question.