Ingo, Thanks for a detailed response, really. It is my fault that I did not set the context and here it is: a. The old firewall is in production and is running as expected - blocking and passing as we need. b. I am in the process of replacing it with a new one. It happens that OpenBSD was inconvenient on the hardware we have, so the new firewall is implemented on FreeBSD. I copied most stuff over and tested it within our network - which is not a complete test. c. So, one test is to put these two firewalls in tandem - just for testing. The idea being that the inside firewall will catch stuff going out and we can see it in the logs and the outside firewall will catch stuff coming in and we can see that as well. They should not have anything in the logs for stuff going the other ways. if you know what I mean.
d. Why are we performing a test like this? We are replacing a production firewall and want to test the new one for about a month before taking the old one away. Is there a better way to test out the functionality over an extended period of time - without setting up a separate environment? e. The tandem configuration got hooked in and everything (by 'everything, I mean this is our single pipe in and out of our organization and we have a lot of other services we provide) works except smpts, https and maybe imaps and pop3s (we did not test for these since we quickly reverted back when we found out that some services were being blocked) OLD FIREWALL - smtps pfctl -s rules|grep 465 pass in log quick on em0 inet proto tcp from any to 128.114.23.233 port = 465 flags S/SA modulate state pass in log quick on em0 inet proto tcp from any to 128.114.23.234 port = 465 flags S/SA modulate state pass in log quick on em0 inet proto tcp from any to 128.114.22.166 port = 465 flags S/SA modulate state pass in log quick on em0 inet proto tcp from 66.59.235.49 to 128.114.23.218 port = 465 flags S/SA modulate state em0 is the outside port of the bridge NEW FIREWALL - smtps pfctl -s rules|grep smtps pass in log quick on em0 inet proto tcp from any to 128.114.23.233 port = smtps flags S/SA modulate state pass in log quick on em0 inet proto tcp from any to 128.114.23.234 port = smtps flags S/SA modulate state pass in log quick on em0 inet proto tcp from any to 128.114.22.166 port = smtps flags S/SA modulate state pass in log quick on em0 inet proto tcp from 66.59.235.49 to 128.114.23.218 port = smtps flags S/SA modulate state OLD FIREWALL and NEW FIREWALL imaps DATA is the same pfctl -s rules|grep imaps pass in log quick on em0 inet proto tcp from any to 128.114.23.233 port = imaps flags S/SA modulate state pass in log quick on em0 inet proto tcp from any to 128.114.23.234 port = imaps flags S/SA modulate state OLD FIREWALL and NEW FIREWALL https DATA is the same pfctl -s rules|grep https pass in log quick on em0 inet proto tcp from any to 128.114.23.233 port = imaps flags S/SA modulate state pass in log quick on em0 inet proto tcp from any to 128.114.23.234 port = imaps flags S/SA modulate state OLD FIREWALL and NEW FIREWALL pop3s DATA is the same pfctl -s rules|grep pop3s pass in log quick on em0 inet proto tcp from any to 128.114.23.233 port = pop3s flags S/SA modulate state pass in log quick on em0 inet proto tcp from any to 128.114.23.234 port = pop3s flags S/SA modulate state Yudhvir === On Sun, May 17, 2009 at 11:09 AM, Ingo Schwarze <schwa...@usta.de> wrote: > mehma sarja wrote on Sun, May 17, 2009 at 10:35:27AM -0700: > > > I want to test two pf firewalls in-line - an old openBSD (3.7 #50, > > That makes absolutely no sense. Don't run real servers with historical > software. Run 4.5. > > > i386) is on the 'outside' and a new FreeBSD (7.2 #0 amd64) is on > > the 'inside.' > > Using an external and an internal router with a border net (DMZ) > in between is *the* standard way to run a firewall. Certainly, > there are other possibilities, but's that's what you usually do > when you have the resources. > > > Here is the setup INTERNET ===[outside port bridged to inside > > port OLD pf] === [outside port bridged to inside port NEW pf] === LAN > > That doesn't sound well. Bridging should definitely not be involved. > In a traditional internal/external firewall setup, bridging is > particularly counter-productive. > > > I took the old pf.conf and am using it in the new machine. > > The setup blocks smpts and https verifiably. > > Perhaps also imaps and pop3s. > > That does not sound well. "Perhaps" should not be involved when setting > up a firewall. Pay attention to use a default-deny policy. > > > Any help will be taken as grateful relief. > > Start by reading a standard textbook about firewall design. > > Yours, > Ingo
