Hi,
I noticed that processing order of ipsec and ipfw (pfil_hook) is not
correct for outgoing packets. Currently, ipsec processing is done first,
which makes packets to go through without firewall inspection.
This might be a security problem for someone, but at least it
breaks stateful rule handli
Ollie Cook wrote:
Good afternoon,
I am currently writing a potentially high bandwidth (think fileserver)
application which will proxy data from one PF_INET socket to another (no reason
it has to be PF_INET, but that's how the application stands).
At the moment this is implemented as follows (in ps
In message <[EMAIL PROTECTED]>, you wrote:
>On Thu, Oct 28, 2004 at 12:51:09PM -0700, Ronald F. Guilmette wrote:
>> What conditions may cause connect(2) to yield EPERM on 4.10-RELEASE?
>
>Being blocked by your own firewall is the one I can come up with...
YES!
Thank you for pointing this out.
On Fri, 29 Oct 2004 16:14:11 +0200, Jeremie Le Hen <[EMAIL PROTECTED]> wrote:
> IIRC, I read somewhere this is precisely the reason why enc(4) was
> written.
Yep, that seems to be exactly what I need. I don't suppose there are
any plans to implement something similar in FreeBSD anytime soon?
Con
> Rather than a "problem" with ipfw however, I think I've got a
> fundamental problem with how to do this. If I understand correctly, in
> order for natd to "reverse" a divert rule (translate the destination
> IP back to the original IP on return traffic) the packet has to come
> through the same i
Good afternoon,
I am currently writing a potentially high bandwidth (think fileserver)
application which will proxy data from one PF_INET socket to another (no reason
it has to be PF_INET, but that's how the application stands).
At the moment this is implemented as follows (in pseudo-C; no error-
