All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Frost <sfrost@snowman.net>
To: Patrick McHardy <kaber@trash.net>
Cc: netfilter-devel@lists.netfilter.org
Subject: Re: ipsec patches test: minor compilation and policy match issues
Date: Tue, 13 Jul 2004 12:10:21 -0400	[thread overview]
Message-ID: <20040713161021.GO21419@ns.snowman.net> (raw)
In-Reply-To: <40F4062B.9060308@trash.net>

[-- Attachment #1: Type: text/plain, Size: 1158 bytes --]

* Patrick McHardy (kaber@trash.net) wrote:
> Stephen Frost wrote:
> >Ahhh, now that makes much more sense.  I just had 'require' before.  I'm
> >getting closer it seems.  Now, at least, I seem to be able to match the
> >number I put after the 'unique:' using '--reqid'.  Still doesn't work
> >when using '--spi' though.  Not sure that I care though, unless someone
> >can tell me a reason why I should?  It's important, of course, to match
> >the right packets, since I'm doing tunneling and different remote sites
> >will have access to different things and so different firewall rules to
> >handle them...
> 
> Ooops, right, that was the --reqid option. I need to update the manpage
> again ;) Not sure what the problem with --spi is, I will test is myself
> soon.

Okay, thanks.  For --reqid...  Do you think that's sufficient to base
firewall rules off of?  Can it be somehow 'faked' by the
remote/potentially untrusted side?  That's my main issue.  If it can't
and will only match if the ipsec packet is valid and coming from that
network then I don't need to care about --spid and will just use
--reqid...

	Thanks,

		Stephen

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2004-07-13 16:10 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-15 21:20 ipsec patches test: minor compilation and policy match issues Ivan Mitev
2004-04-16 14:11 ` Patrick McHardy
2004-04-24 10:17   ` Ivan Mitev
2004-04-24 11:14     ` Patrick McHardy
2004-04-24 11:51       ` Patrick McHardy
2004-04-24 13:07         ` Ivan Mitev
2004-04-27 18:58     ` Michael Richardson
2004-04-28  0:30       ` Patrick McHardy
2004-04-16 15:21 ` Where is DROP target implemented {Virus Scanned} Qiang
2004-04-16 16:39   ` Patrick McHardy
2004-07-13  2:37 ` ipsec patches test: minor compilation and policy match issues Stephen Frost
2004-07-13  2:54   ` Patrick McHardy
2004-07-13 11:53     ` Stephen Frost
2004-07-13 15:56       ` Patrick McHardy
2004-07-13 16:10         ` Stephen Frost [this message]
2004-07-14  1:22           ` Patrick McHardy
2004-07-14  3:00             ` Stephen Frost
2004-07-14 12:11               ` Patrick McHardy
2004-07-14  3:37             ` Henrik Nordstrom
2004-07-14 12:25               ` Patrick McHardy
2004-07-14 15:05                 ` Henrik Nordstrom
2004-07-23  0:06                   ` Patrick McHardy
2004-07-25  9:40                     ` Henrik Nordstrom

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=20040713161021.GO21419@ns.snowman.net \
    --to=sfrost@snowman.net \
    --cc=kaber@trash.net \
    --cc=netfilter-devel@lists.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.