silly pf config issues

[Jens Ropers]

DISCLAIMER: I'm still fairly n00bish, I don't really know what I'm
talking about, take what I'm saying with truckloads of salt. That
said, here are my two
http://en.wikipedia.org/wiki/Eurocent s:

> From: Bulk Mail <bulk at szmidt.org>
> Subject: silly pf config issues
> To: openbsd-newbies at sfobug.org
> Message-ID: <200609081454.44227.bulk at szmidt.org>
> Content-Type: text/plain;  charset="us-ascii"
>
> Hi,
>
> I'm stuck on something obvious and I don't seem to be able to catch it.
>
> I got a small test subnet 192.168.0.0 under my own subnet 10.1.0.0, where I
> test this firewall.
>
> Internet--[firewall]--10.1.0.0--[this test firewall]--192.168.0.0
>
> Queues are not active yet, nor are web or ftp servers.
> I added a test machine IP (192.138.0.2) to the managers table file, and
> 10.1.0.34  + google.com as allowed web sites for testing purposes.
>
> I can ping them by both IP and domain name, but not browse.

I'm assuming you're sitting in front of 192.138.0.2 and you're trying
to reach 10.1.0.34 and google.com both with icmp and tcp 80 traffic.
If not please clarify and disregard what I'm saying below.

> ## Macros
> # Interfaces
> WAN="bge0"
> LAN="xl0"
> LANip="192.168.0.0/24"

Minor nitpicking: I would have named WAN and LAN internal_interface
and external_interface or somesuch, just to emphasize (to myself) the
fact that I'm talking about the *interface* here and not the (sub)net
that it's connected to -- but that's just a personal preference.

> RFC1918="{ 127.0.0.0/8 192.168.0.0/16 172.16.0.0/12 10.0.0.0/24 }"
> #RFC1918="{ 127.0.0.0/8 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8  }"
>
> Web="{ 80, 443 }"
> Web-server="192.168.0.2"
> Ftp="21"
> Ftp-server="192.168.0.2"
>
> ## Tables       (Content in brackets)
> table <admins> file "/etc/tAdmins" ( )
> table <managers> file "/etc/tManagers" (192.168.0.2)
> table <operators> file "/etc/tOperators" (192.168.0.128/26)
> table <http-managers> file "/etc/tHttp-managers" (google.com)
> table <http-operators> file "/etc/tHttp-operators" (example.com)
> table <customers> file "/etc/tCustomers" ( )
> table <extadmin> file "/etc/tExtadmin" ( )

The same minor nitpicking point I made about WAN and LAN applies here
as well. I personally don't find user/group names such as managers,
operators and somesuch to be really useful when you're really talking
about *computers, not their users*.

> ## Options
>
> ## Traffic Normalization
> scrub in all
>
> ## Bandwidth Management
> altq on $WAN cbq bandwidth 3000Kb queue { ssh, http-out, http-in, ftp-in,
> mail, dns, ftp, misc }
> #queue LOCAL bandwidth 98456Kb cbq(borrow)
>
> queue ftp-in bandwidth 12% priority 4 cbq(borrow red)
> queue http-in bandwidth 13% priority 4 cbq(borrow red)
> queue http-out bandwidth 25% priority 3 cbq(borrow red) { develusers,
> normalusers }
> queue  develusers bandwidth 50% cbq(borrow)
> queue  normalusers bandwidth 50% cbq(borrow)
> queue mail bandwidth 10% priority 1 cbq(borrow ecn)
> queue dns bandwidth 5% priority 5 cbq(borrow ecn)
> queue ftp bandwidth 15% priority 2 cbq(borrow ecn)
> queue ssh bandwidth 10% priority 6 cbq(borrow) { ssh_interactive, ssh_bulk }
> queue  ssh_interactive bandwidth 50% cbq(borrow)
> queue  ssh_bulk bandwidth 50% cbq(borrow)
> queue misc bandwidth 10% cbq(borrow,default)

As long as you're troubleshooting I would completely disable queueing,
just to rule out any probs there.

> ## Translations
> #special = "{ 10.2.1.10 }"
> #no nat on $WAN from $special to any
> #nat on $WAN from $LAN to any -> $WAN
> #binat on $WAN from $special to any -> $WAN
>
> nat on $WAN from $LAN:network to any -> $WAN
>
> ## Redirection
>
> ## Packet Filtering
> # Allow all loopback traffic.
> pass quick on lo0
>
> # Default deny.
> block in  log quick on $WAN from $RFC1918
> block in  log on $WAN
> block out log on $WAN
>
> # Allow basic networking communication
> pass in  log on $WAN proto icmp from any to any keep state
> pass out log on $WAN inet proto icmp all icmp-type 8 code 0 keep state
>
> # Allow dns and ntp out
> pass out log on $WAN proto udp from any to any port 53 keep state
> pass out log on $WAN proto udp from any to any port 123 keep state
>
> # Allow ssh in and out
> pass in  log on $WAN proto tcp from any to any port 22 keep state
> pass out log on $WAN proto tcp from any to any port 22 keep state
>
> # Allow web out based on tables
> pass in  log on $LAN proto tcp from <managers> to any port $Web keep state
> pass out log on $WAN proto tcp from <admins> to any port $Web keep state
> pass out log on $WAN proto tcp from <managers> to <http-managers> port $Web
> keep state
> pass out log on $WAN proto tcp from <operators> to <http-operators> port $Web
> keep state

I would only filter traffic on ONE interface, as is often recommended
in applicable documentation -- e.g. just filter traffic on your $WAN
interface. It's very hard to get things right when filtering on two
interfaces. So I would default deny (block all), then pass quick on
$LAN and then pass on $WAN as required.

Also, you don't seem to be passing proto tcp, port 80 traffic from
<managers> (ie. 192.168.0.2) to the 10.1.0.34 box on the $WAN
interface?  Keep in mind that <http-managers> contains only google.com
and <admins> is empty. You're passing traffic from 10.1.0.34 to any
port 80 on the $LAN interface, but not on the $WAN one. I think
there's your reason you can't websurf to 10.1.0.34.

As for google.com, I'm not sure, but I think it might have something
to do with the fact that google.com resolves to multiple IPs in a
round robin fashion -- and your <http-managers> only resolves to just
one of Google's IPs at pf.conf load time. So when during your
subsequent webbrowsing you're sending a DNS request for google.com,
and a different IP is returned than the one google.com resolved to
when pf loaded your rules, the IPs don't match, the rule doesn't match
and your traffic is blocked. (I could be wrong here, though, as I
said, this is largely conjecture and I don't really know what I'm
talking about. Also, if my assumption here is correct then I'm not
quite sure right now how that could best be fixed.)

> # Allow web and ftp in based on table
> #pass in log on $WAN proto tcp from <customers> to $Web-server port $Web
> #pass in log on $WAN proto tcp from <customers> to $Ftp-server port $Ftp

cheers,
Jens