Persistence in connection tracking for port forwarded traffic?

Grant Taylor gtaylor at
Fri Aug 12 07:22:12 CEST 2005

ng techorder wrote:
> Hello Everyone, 
>    If I am double posting to the list, my apology.  I
> seem to not see my previous post within the archive.
>    I need some assistance in getting this Multi-WAN'ed
> linux box working correctly.  The box is multi-WAN'ed
> because I want to only present a single gateway to the
> machines on the LAN, yet take advantage of always
> having a path to the internet if one of the ISP goes
> down.
>    Onward to the problem.  From the LAN side, I can
> surf the internet with no problem.  However, I am
> encountering issues when I try to provide
> port-forwarded services like FTP, HTTP to servers
> located on the LAN side.  
>    For example, I am port forwarding all HTTP request
> from the WAN to to an internal server
> located at  About 50% of the time, that
> worked normaly.'s reply packets went
> back out on the interface.  However,
> on the other 50% of the time, the reply packet went
> out on the interface, and the
> client's web browser just timed out because it ignored
> this "unrelated" reply packet.  
>    This can happen on the start of the new connection
> (where the client's browser never got the correctly
> sourced initial reply packet), or midway throught the
> webpages access session.
>    How do I get the system to send the reply back on
> the correct interface all the time?  A big thank you
> in advance.

I could be wrong about this.  I have not tested any of what I am about to propose so take it with a grain of salt or two...

I would be tempted to see if I could not get the connection marking extensions to help you out in this endeavor.  As I understand it the connection marking will recognize the traffic for a connection in either direction and thus be able to mark it accordingly.  With this in mind I would be tempted to connmark the packets that come in one interface with a mark value that you associate with said interface and then mark connections that come in another interface(s) with another mark value that you associate with the other interface(s).  I believe you could then use some ip rules to determine the correct routing table to use based on the connection mark and thus ensure that traffic will go out the correct interface.  Again this is just and idea and is far from working but it is also where I would start.

Can any one else comment on CONNMARK?

Grant. . . .

More information about the netfilter mailing list