> -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
> 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
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
I don't know what the reasons are, but I know the result.
After much frustrating reasearch I came to the conclusion that I can:
a) use linux (not an option as far as I'm concerned)
b) use openvpn
I need to create a hub and spoke type of vpn arrangement - one spoke node
needs to communicate with
