All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Jesper Dangaard Brouer <hawk@diku.dk>
Cc: pablo@netfilter.org, netfilter-devel@vger.kernel.org,
	netdev@vger.kernel.org, mph@one.com, jesper.brouer@gmail.com,
	as@one.com
Subject: Re: [PATCH 0/5] netfilter: SYNPROXY target v3
Date: Tue, 27 Aug 2013 11:05:24 +0200	[thread overview]
Message-ID: <20130827090523.GB9805@macbook.localnet> (raw)
In-Reply-To: <Pine.LNX.4.64.1308270951520.25216@ask.diku.dk>

On Tue, Aug 27, 2013 at 10:35:56AM +0200, Jesper Dangaard Brouer wrote:
> On Tue, 27 Aug 2013, Patrick McHardy wrote:
> 
> >Since the SYN proxy can't know the options the server supports, they have
> >to be specified as parameters to the SYNPROXY target. The assumption is that
> >these options are constant as long as you don't change settings on the
> >server.
> 
> Future extention idea: Perhaps we could auto detect the options the
> server supports, after the first connection have been created?
> I know this is problematic/difficult for the iptables framework,
> because it would require the module to keep an internal dynamic
> state, which iptables module does not handle well (due to how the
> entires ruleset is reloaded on rule changes).

The main reason why I didn't add this is since it assumes you have a
single rule per destination. That assumption can't be made, so you'd
have to maintain a table of options per destination.

I'll add the synconf tool to generate rules based on what the server
actually supports to the iptables repository once this has been merged.

> Guess, the easiest thing to implement, would be to give a warning,
> if the options (the server supports) does not match the modules config.

Yes, that could be done.

  reply	other threads:[~2013-08-27  9:05 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-27  6:50 [PATCH 0/5] netfilter: SYNPROXY target v3 Patrick McHardy
2013-08-27  6:50 ` [PATCH 1/5] netfilter: nf_conntrack: make sequence number adjustments usuable without NAT Patrick McHardy
2013-08-27  6:50 ` [PATCH 2/5] net: syncookies: export cookie_v4_init_sequence/cookie_v4_check Patrick McHardy
2013-08-27  6:50 ` [PATCH 3/5] netfilter: add SYNPROXY core/target Patrick McHardy
2013-08-27  6:50 ` [PATCH 4/5] net: syncookies: export cookie_v6_init_sequence/cookie_v6_check Patrick McHardy
2013-08-27  6:50 ` [PATCH 5/5] netfilter: add IPv6 SYNPROXY target Patrick McHardy
2013-08-27  8:35 ` [PATCH 0/5] netfilter: SYNPROXY target v3 Jesper Dangaard Brouer
2013-08-27  9:05   ` Patrick McHardy [this message]
2013-08-27 12:08   ` Jesper Dangaard Brouer
2013-08-27 12:05 ` Martin Topholm
2013-08-27 22:49 ` Pablo Neira Ayuso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130827090523.GB9805@macbook.localnet \
    --to=kaber@trash.net \
    --cc=as@one.com \
    --cc=hawk@diku.dk \
    --cc=jesper.brouer@gmail.com \
    --cc=mph@one.com \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.