All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rick Kennell <kennell@ecn.purdue.edu>
To: George Vieira <georgev@citadelcomputer.com.au>
Cc: netfilter@lists.netfilter.org
Subject: RE: port-based filtering of IPsec packets?
Date: 25 Jul 2003 01:14:43 -0500	[thread overview]
Message-ID: <1059113683.16545.162.camel@k7.localnet> (raw)
In-Reply-To: <09B04A55822EFF4DA48D2E0BB2941D4A0192CB@wardrive.citadelcomputer.com.au>

On Thu, 2003-07-24 at 16:37, George Vieira wrote:
> >Surely there must be some way of doing port-based filtering of ESP
> >packets that are known to be bound for the local host.
> If the packet isn't intended for the firewall/ipsec server, then
> it's forwarded unencrypted to the internal hosts.... I'm sure by
> then the data in decrypted right? Because it can't pass an encrypted
> packet to a host who isn't using IPSEC.
> 
> Can you put -j LOG rules in the FORWARD chain to filter on it?
> Mine appear to pickup port 23 telnet sessions... sorry if what
> you want isn't this..
> 
> 
> [root@firewall root]# iptables -I FORWARD -i ipsec0 -o eth0 -p tcp --dport 23
> [root@firewall root]# iptables -L FORWARD -n -v -x
> Chain FORWARD (policy DROP 0 packets, 0 bytes)
>     pkts      bytes target     prot opt in     out     source               destination
>        2      104            tcp  --  ipsec0 eth0    0.0.0.0/0            0.0.0.0/0          tcp dpt:23

You're using FreeS/WAN, and you're right that it creates an ipsec0
network device where you can see unencapsulated packets.

Meanwhile, I'm using the IPsec built-in to Linux v2.6.
No user-land daemon.
No ipsec0 device.
And no port-based filtering of ESP packets.

Maybe what I'm asking is going to be a FAQ in a few months when the
in-kernel IPsec catches on.  I'm fairly convinced that port- or
payload-based filtering of IPsec packets isn't presently possible with
such that environment.  Either something needs to change or I need to
get a little smarter.

Time to bother the folks on netfilter-devel?

-- 
Rick Kennell <kennell@ecn.purdue.edu>
Purdue University School of Electrical and Computer Engineering



  reply	other threads:[~2003-07-25  6:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-24 21:37 port-based filtering of IPsec packets? George Vieira
2003-07-25  6:14 ` Rick Kennell [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-07-23 19:35 Rick Kennell
2003-07-23 20:42 ` Ramin Dousti
2003-07-23 21:11   ` Garcia Ruiz
2003-07-23 21:23     ` Rick Kennell
2003-07-24  1:08       ` Ramin Dousti
2003-07-24 20:50         ` Rick Kennell
2003-07-24 21:36           ` Ramin Dousti
2003-07-23 21:30     ` James A. Pattie

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=1059113683.16545.162.camel@k7.localnet \
    --to=kennell@ecn.purdue.edu \
    --cc=georgev@citadelcomputer.com.au \
    --cc=netfilter@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.