On Wednesday 10 May 2006 09:07, NetNeanderthal wrote:
> On 5/9/06, Ashley Moran <[EMAIL PROTECTED]> wrote:
> You're way off on what you're trying to do and need to seriously
> consider re-reading the PF FAQ and/or trying the examples. This being
> said...
Thanks for the detailed reply. It was REALLY helpful. I'm not our network
administrator here, although I seem to get lumbered with all the hard jobs.
I'm also rushed to get the firewalls up and running so no wonder I've made a
mess :-S
> > udp_opts = "keep state"
> > icmp_opts = "keep state"
>
> These are just making the waters muddy -- if you use 'flags S/SA
> modulate state' for all connections, PF will interpret what you mean
> for udp and icmp connections -- try it out.
I wanted to avoid S/SA because we have two firewalls I want to redundantly
cluster and don't want any service interuption when we pull one down (we have
a lot of long-lived connections into our servers).
> > nat_proto = "{ tcp, udp, icmp }"
>
> ew? Don't do this.
Hmmm, I got this from Jacek Artymiak's Building Firewalls with OpenBSD and PF.
I figured if anything was a good source of copy-and-paste that was it!
>
> > scrub all reassemble tcp
> > scrub in all fragment reassemble
> > scrub out all random-id
> >
> > nat on $ext_if proto $nat_proto \
> > from $webserv2_dmz_ad -> $webserv2_ext_ad
> > rdr on { $ext_if, $int_if } proto tcp \
> > from any to $webserv2_ext_ad port www -> $webserv2_dmz_ad port www
> >
> > block in log (all) all
> > block out log (all) all
>
> You can just use 'block log' to simplify this -- the rest is implied
> and unnecessary.
Ditto re source...
>
> > antispoof log quick for $antispoof_if
>
> $antispoof_if is undefined
Sorry, forgot to copy it in the e-mail. I tried to exclude anything related
to our internal network (ie not the DMZ or internet)
>
> > pass out on $ext_if proto tcp \
> > from any to any $tcp_opts
> > pass out on $ext_if proto udp \
> > from any to any $udp_opts
> > pass out on $ext_if inet proto icmp \
> > from any to any $icmp_opts
>
> Ok, so this whole mess could be rewritten as follows, though I wonder
> why you would do it in such a fashion:
> pass out on $ext_if proto {tcp, udp, icmp} from any to any modulate state
> - or -
> pass out on $ext_if proto {tcp, udp, icmp} modulate state
>
> > pass in on $dmz_if proto tcp \
> > from $dmz_ad to any port $dmz_tcp_services_out #$tcp_opts
> > pass in on $dmz_if proto udp \
> > from $dmz_ad to any port $dmz_udp_services_out #$udp_opts
> > pass in on $dmz_if proto icmp \
> > from $dmz_ad to any #$udp_opts
>
> Blah, don't use complicating macros while you're learning PF!
>
> > Call dig with this setup and it times out; uncomment the options
> > (modulate/keep) state and you get a DNS result. I was under the
> > impression that the state should be created as the packets leave $ext_if,
> > so why is it necessary to put a state option in the DMZ interface rules?
> >
> > Hope someone can clear this up
>
> I'm just not sure what it is you're trying to accomplish. Is this
> simply a two-interface firewall that is performing NAT for a web/dns
> server to the outside world?
No, this is a 3-interface firewall that seperates our corporate network from
our DMZ from the internet. We will have webservers in the DMZ but no DNS
servers.
What I noticed initially was that SSH sessions were taking forever to connect
which is a sure sign that DNS is down. So I used dig from the webserver and
sure enough, I couldn't make a DNS query, despite the "pass out on $ext_if
keep state" rule. However, when I added a "keep state" option to the $dmz_if
on the pass *in* rule it worked. I couldn't see why a state wasn't being
made as packets left the external interface.
I've modified my rule set according to your examples and it's working fine
now.
> pfctl -sa is your friend -- examine the changes you make before and
> after ruleset load so you can see how PF expands rules. The
> policy-based routing tags will also simplify your life so you only
> have to manage inbound traffic (excepting the firewall's requests
> itself - ssh, ntp, dns, et al).
I'm quite fond of tcpdump too! I got nowhere until I started examining the
packets.
And I hadn't used tags before but I can see how they can simplify the rules a
lot.
Regards
Ashley
--
"If you do it the stupid way, you will have to do it again"
- Gregory Chudnovsky
