| To: | Andreas Jellinghaus <aj@xxxxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: port-based filtering of ESP packets with in-kernel IPsec? |
| From: | Dax Kelson <dax@xxxxxxxxxxxx> |
| Date: | 30 Jul 2003 16:51:34 -0600 |
| Cc: | Harald Welte <laforge@xxxxxxxxxxxxx>, netfilter-devel@xxxxxxxxxxxxxxxxxxx, netfilter@xxxxxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx |
| In-reply-to: | <1059597421.3284.7.camel@xxxxxxxxxxxxxxxxxxx> |
| References: | <1059540296.16545.305.camel@xxxxxxxxxxx> <20030730142411.GD4553@xxxxxxxxxxxxxxxxxxxxxxx> <1059576701.4586.20.camel@simulacron> <1059597421.3284.7.camel@xxxxxxxxxxxxxxxxxxx> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
On Wed, 2003-07-30 at 14:37, Dax Kelson wrote: > On Wed, 2003-07-30 at 08:51, Andreas Jellinghaus wrote: > > [netfilter] > > incoming encrypted packets are seen as ESP/AH in INPUT > > and then as decrypted packet in INPUT or FORWARD. > > Just to clarify, the packets will travel INPUT *twice* (once as ESP and > then in the clear)? If this is the case, then I see a problem. If you have an explicit drop/reject all the bottom (or have a DROP policy) of INPUT then no IPSEC traffic would be allowed. I supposed you could add a rule that allowed all ESP traffic before the the explicit drop. Dax |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: port-based filtering of ESP packets with in-kernel IPsec?, Dax Kelson |
|---|---|
| Next by Date: | Re: [PATCH][ATM][2.4] export try_atm_clip_ops not atm_clip_ops_mutex, David S. Miller |
| Previous by Thread: | Re: port-based filtering of ESP packets with in-kernel IPsec?, Dax Kelson |
| Next by Thread: | [PATCH 0/5] [bonding] backport 2.6 changes to 2.4, Amir Noam |
| Indexes: | [Date] [Thread] [Top] [All Lists] |