Alaor Barroso de Carvalho Neto wrote:
> nat on $ext_if from $internal_nets to any -> ($ext_if)
> nat on $cefet_if from $adm_net to any -> ($cefet_if)
> rdr on $all_if proto tcp from any to any port $proxy_ports \
> -> 127.0.0.1 port 3128
OK, so do these nat rules actually take effect? Which one? Why do you
need nat from adm_net to cefet_net? It appears there is no such need,
but then could require a change on cefet_net to tell these hosts the
route to adm_net.
It is possible that the rdr rule applies even though it appears under
the nat rule because rdr is applied on the way in while nat is applied
on the way out. rdr is only applied to tcp, the nat rule then is applied
to udp and icmp - this will explain why you can ping but not connect
with tcp.
You can add log statements to your nat rules to see which is applied.
pass quick proto icmp from any to any keep state
pass quick from $adm_net to $cefet_servers keep state
pass quick from $cefet_servers to $adm_net keep state
It appears that ping is passed by the first rule, but other protocols
are not matched in the second/third rule.
block quick from any to $cefet_net
block quick from $cefet_net to any
Then it is probably blocked here.
Some general considerations:
When writing your ruleset, make sure to add log in any block statement.
That will show you which rule is applied when a packet is blocked. Once
things are working remove log statements.
Make your rules as specific as possible. State direction and interfaces
and avoid the use of "any". It is easier to avoid that some other rule
take effect than the one you intended.
"any" and lack of direction/interface is fine in policy rules - that is
when you explicitly state "block all".
I usually build my rules like this:
block all # default policy
block in all
block in on $ext_if all
...
block in quick on $ext_if all
...
block in quick all
block out all
...
block out quick all
block quick all # catch up just in case I messed up
It makes it easy to locate any error, and it actually also follows the
rules of the pf skip ahead optimizer.
Cheers, Erik
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
