[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pf NAT confusion



[OK, I've subbed to the list so I shouldn't break any more threaded
Web-based archives...though I think at least some would make a good
guess. -Joel]

Ben Goren wrote:

[...]
> If you allow access to unrestricted IPs with restricted ports, a
> ``bad guy'' will just set up a server of his choice to listen on one
> of the ports you do allow out.
[...]
> If you really want to decide what is and isn't okay to let out, you
> need to proxy *everything.*

You are indeed correct that network-level firewalls are unaware of the
application-level traffic that passes through them; however, the list of
services we support is not limited to those listed in the original post
(that was just the point in testing where we learned of the problem),
and we are not at this point looking to migrate from network-level
firewalling/NAT to proxy servers.

> Because of the interactions of NAT and state keeping, the general
> method to accomplish what you describe is basically the same as
> what's done with a bridging firewall: pick an interface to filter
> on, and let everything else through on the other(s). You could, for
> example, let everything go through the Internet side of the
> firewall, but only permit selected outbound packets to your servers
> (with keep state) and selected inbound packets from your proxy
> server on the workgroup network. You could still reject all
> non-routeable addresses, spoofs, and the like that appear on the
> Internet side.

As I mentioned, we saw that NATted traffic passed through just fine if
we opened outbound traffic on the Net-side interface of the firewall,
but that the connection was never made if we merely relied on the rule
of our workgroup interface.  If the only solution to this problem is to
open all traffic from the firewall, that will resolve the problem we
presently want to solve, as the outbound server network traffic is
restricted; however, the solution is not elegant or ideal.  The setup we
desire did work in IP Filter, but the FAQ does not mention the behavior
we're seeing as a difference between the two, so either it's not (yet?)
supported or I'm missing something the FAQ and manpages -- which are
generally excellent -- haven't clued me in on.

Joel