> -Original Message-
> From: Mitch (bitblock) [mailto:[EMAIL PROTECTED]
> Sent: Saturday, July 31, 2004 3:35 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: ipsec packet filtering
> > But by adding the following option to the kernel conf
> >file you
> But by adding the following option to the kernel conf file you can get
> the processing path I think you are asking for??
>
> options IPSEC_FILTERGIF (documented in LINT)
>
> This then causes the decrypted packet to be passed thru IPFW again.
>
> Be aware this has significant conseq
Hello Bjoern,
Friday, July 30, 2004, 12:12:52 PM, Bjoern A. Zeeb wrote:
>> see? if the incoming packet is not in table, _and_ natd is not running
>> in proxy_only mode (which is not acceptable here) the packet flows by
>> without any change. And that's what the `man natd' says.
BAZ> please type
On Fri, 30 Jul 2004, Nickolay A. Kritsky wrote:
Hi,
> I think I have got your point here, but filtering esp in tunnel mode
> is of no use in many scenarios since higher protocol information (like
> ports for TCP/UDP) is hidden in encrypted payload.
at first it helps you to accept (only) encrypte
> From searching the archives this looks like an old issue, but I
> still can't understand something.
> AFAIU, now the ipfw + ipsec interoperation looks like this:
> input: encrypted packet comes to system. It is not checked against
> ipfw rules. Rules are applied to decrypted payload pac
Hello Bjoern,
Friday, July 30, 2004, 11:02:26 AM, Bjoern A. Zeeb wrote:
>> Then I do (on VPN_router2):
>> bash-2.05b# uname -sr
>> FreeBSD 4.9-RELEASE
BAZ> ok; for the 'ipsec' ipfw option this is too old. It's been functional
BAZ> in 5.x since 2003-12-02, that is 5.2, 5.2.1, HEAD and in RELENG_4
On Fri, 30 Jul 2004, Nickolay A. Kritsky wrote:
> OK. let's place a small demonstration.
>
> 217.195.82.43 <-->VPN_router1 <--> [---INTERNET---]
> |
> |
> 192.168.64.10 <---> VPN_router2
>
> Traffic
Hello Bjoern,
Friday, July 30, 2004, 9:04:49 AM, Bjoern A. Zeeb wrote:
BAZ> I do not understand what your are trying to do but filitering ipsec
BAZ> encrypted packets in ipfw is available for quite some time now.
BAZ> I can and do check packets that:
BAZ> - come in encrypted and leave unencrypted
On Fri, 30 Jul 2004, Nickolay A. Kritsky wrote:
> Hello freebsd-net,
>
> From searching the archives this looks like an old issue, but I
> still can't understand something.
> AFAIU, now the ipfw + ipsec interoperation looks like this:
> input: encrypted packet comes to system. It is not ch
mailto:[EMAIL PROTECTED] Behalf Of Nickolay A. Kritsky
> Sent: Thursday, July 29, 2004 8:59 PM
> To: [EMAIL PROTECTED]
> Subject: ipsec packet filtering
>
>
> Hello freebsd-net,
>
> From searching the archives this looks like an old issue, but I
> still can't un
Hello freebsd-net,
From searching the archives this looks like an old issue, but I
still can't understand something.
AFAIU, now the ipfw + ipsec interoperation looks like this:
input: encrypted packet comes to system. It is not checked against
ipfw rules. Rules are applied to decrypted p
On 2003.06.19 21:33:33 +0300, Ari Suutari wrote:
> Hi,
>
> > * Ari Suutari:
> >
> > > Here are two small patches (done on 5.1-RELEASE, but should be ok
> > > for -current also) which add new "ipsec" flag to ipfw2.
> >
> > i did not receive any attachments. will this functionality be
> > include
Hi,
> * Ari Suutari:
>
> > Here are two small patches (done on 5.1-RELEASE, but should be ok
> > for -current also) which add new "ipsec" flag to ipfw2.
>
> i did not receive any attachments. will this functionality be
> included into freebsd-5 in the future?
Does the mailing list strip at
Hi,
Here are two small patches (done on 5.1-RELEASE, but should
be ok for -current also) which add new "ipsec" flag to ipfw2.
Rules with this flag match only packets that have
ipsec history (ie. came from ipsec processing). Rules with
"not ipsec" match only non-ipsec packets. Without
the new keywo
14 matches
Mail list logo
