>
> 3.2 will not mark the traffic and do any of the special transparent traffic
> handling unless one of the NAT lookups functions returns true. Just relying
> on the default getsockname() is not sufficient to mark the traffic for
> special handling.
>
> Fortunately the "ipfw" NAT lookup does what the new PF version apparently
> needs. The --enable-ipfw-transparent should work as a temporary measure.
with --enable-ipfw-transparent, it works with already known this below error.
Intercept.cc(305) PfInterception: PF open failed: (13) Permission denied
> I would like to fix this so --enable-pf-transparent properly detects and
> handles the version of PF available. Are you able to find out how I could do
> that please?
Will I have to do something from my end ?
-- Thank you Indunil JayasooriyaReceived on Tue Apr 19 2011 - 08:02:06 MDT
This archive was generated by hypermail 2.2.0 : Tue Apr 19 2011 - 12:00:04 MDT