I sometimes forget that the hosts in the DMZ need a default route set to the IP address of the DMZ interface.
Code:
# route add default 192.168.100.1
What happened to the redirections of your previous ruleset?
Quote:
#REDIRECTIONS
match in on egress inet proto tcp from any to any port 25 \
rdr-to $mailserver
[snip]
match in on egress inet proto tcp from any to any port 80 \
rdr-to $ftpwebserver
|
Because you have "block log all" default policy you can watch the blocked packets with tcpdump.
Code:
# tcpdump -eni pflog0
Make sure that the pflog0 interface is
up See
man pflog.
Code:
# pass in on $_int from $int_net tag LAN_TO_INET
pass in quick on $_int from $_int:network to !($_dmz:network, $_int) tag LAN_TO_INET
......
pass out quick on $_ext tagged LAN_NAT_TO_INET
This should allow traffic from the internal lan to the internet.
The best way is to build up your pf.conf for each packet flow step by step. (The approach advocated for programming by Niklaus Wirth father of Pascal, Modula etc)
Start with a
block log all
Now add a rule to allow ssh access from your workstation to the router/firewall.
From an xterm on your workstation SSH in to the firewall and run tcpdump on the pflog0 interface.
From an other xterm ssh in and add the tag rules for internal LAN to internet traffic. From another workstation xterm do a
dig yahoo.com Then a
ping -c2 yahoo.com. If that all works try to access the yahoo.com website with a browser.
For testing your DMZ setup please read the gotchas explained in
http://www.openbsd.org/faq/pf/rdr.html#reflect
You can ssh in to your router/firewall multiple times each in different xterm. That way you can check whether the packets really arrive at an interface
To prevent ssh packets from "polluting" your tcpdump output, you can exclude these ssh packets on the internal interface with
tcpdump -ni re0 'not port ssh'.