ok I went ahead and opened up the lo, it still does not work. Adding
pass to the nat statement causes all nated packets to bypass all of the
other filter rules, this is not acceptable. once again the ruleset
works fine on OpenBSD, so what is different about pf on FreeBSD.
I do not believe the problem is in the rules, I repeat this rule set
works 100% in pf on OpenBSD, I have not found any documentation that
states the pf on FreeBSD interprets rules differently than on OpenBSD.
So either there is a difference that I have not found, if so can
somebody tell me what that difference is? or there is a bug in the
FreeBSD pf code, if so does anybody know what it is, and if there is a
work around.
The other possibility is I am missing a compile time setting or a kernel
setting, if so does anybody know what it might be?
Thanks,
Jeff
Jon Simola wrote:
On 7/26/06, Jeffrey Williams <[EMAIL PROTECTED]> wrote:
I am not running anything that is trying to use the loopback interface
on this box.
Blocking traffic on the loopback will cause many odd problems. Always use
set skip on lo
The following rule passes traffic in on the internal interface, "pass in
on $iif inet from $inwr to any keep state", and there is no rule
blocking traffic out on the internal interface.
The problem here is that the NAT translation of the packet takes place
before pass and block rules are processed. NAT'ed packets appear to be
incoming on the internal interface with an IP address of the external
interface. So you can pass all traffic on the internal interface, or
get a little fancier and use tags with NAT:
nat on $ext_if from $int_if:network to !$int_if:network tag NAT ->
($ext_if:0)
pass all tagged NAT keep state
Or for the minimal ruleset:
nat pass on $ext_if from $int_if:network to !$int_if:network -> ($ext_if:0)
_______________________________________________
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
