IPFilter 5.1.1 imported into current

[Hubert Feyrer]

Hi Darren,

packets that match an entry in the state table. Additionally, there
is a new rule - "decapsulate". This has been designed to allow
filtering on "inner headers" of packets that have been encapsulated
in clear text. It will, for example, allow filtering on IPv4 headers
inside of IPv6 packets (or vice versa.)

Is there a chance this can be made into getting NAT working with IPsec,
i.e. when sending, applying NAT on the inside packet before it goes into IPsec processing
(and vice versa)?

In my previous job, we had some hacks for that, and seeing this supported in an official way would be nice.


- Hubert
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Post by Hubert Feyrer
Hi Darren,

packets that match an entry in the state table. Additionally, there
is a new rule - "decapsulate". This has been designed to allow
filtering on "inner headers" of packets that have been encapsulated
in clear text. It will, for example, allow filtering on IPv4 headers
inside of IPv6 packets (or vice versa.)

Is there a chance this can be made into getting NAT working with IPsec,
i.e. when sending, applying NAT on the inside packet before it goes into IPsec processing
(and vice versa)?

I think that this requires something different as a requirement
here is to play with packets when they're passed to IPsec but
before they're encrypted. At present, IPFilter sees packets only
on input and output and at both points in the stack, the inner
packet will be encrypted, correct?

Darren


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hubert Feyrer]

Post by Darren Reed
I think that this requires something different as a requirement
here is to play with packets when they're passed to IPsec but
before they're encrypted. At present, IPFilter sees packets only
on input and output and at both points in the stack, the inner
packet will be encrypted, correct?

IIRC not - on sending, ip_output(?) is called once for the actual packet
to send, and then it's handed - still unencrypted - to IPsec, which then
calls ip_output(?) again. Similar on input.


- Hubert

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de