This is a long and complicated affair. I have warned you and you still persist on reading further. I will try to protect you as much as possible, but please be forewarned.
GOAL I want to test two pf firewalls in-line - an old openBSD (3.7 #50, i386) is on the 'outside' and a new FreeBSD (7.2 #0 amd64) is on the 'inside.' The FreeBSD firewall does NOT have altq enabled. Here is the setup: INTERNET ===[outside port bridged to inside port OLD pf] === [outside port bridged to inside port NEW pf] === LAN CONTEXT 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. WHY ARE WE DOING 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? RESULTS OF TEST 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) DATA THAT MIGHT BE HELPFUL OLD FIREWALL - smtps pfctl -s rules|grep 465 pass in log quick on em0 inet proto tcp from any to 118.124.23.233 port = 465 flags S/SA modulate state pass in log quick on em0 inet proto tcp from any to 118.124.23.234 port = 465 flags S/SA modulate state pass in log quick on em0 inet proto tcp from any to 118.124.22.166 port = 465 flags S/SA modulate state pass in log quick on em0 inet proto tcp from 56.69.235.49 to 118.124.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 118.124.23.233 port = smtps flags S/SA modulate state pass in log quick on em0 inet proto tcp from any to 118.124.23.234 port = smtps flags S/SA modulate state pass in log quick on em0 inet proto tcp from any to 118.124.22.166 port = smtps flags S/SA modulate state pass in log quick on em0 inet proto tcp from 56.69.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 118.124.23.233 port = imaps flags S/SA modulate state pass in log quick on em0 inet proto tcp from any to 118.124.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 118.124.23.233 port = imaps flags S/SA modulate state pass in log quick on em0 inet proto tcp from any to 118.124.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 118.124.23.233 port = pop3s flags S/SA modulate state pass in log quick on em0 inet proto tcp from any to 118.124.23.234 port = pop3s flags S/SA modulate state MY CONJECTURES Referring to one rule: pass in log quick on em0 inet proto tcp from any to 118.124.23.233 port = imaps flags S/SA modulate state FIRST I suspect "modulate state" may be the culprit. Here is what the manual says: "modulate state - works only with TCP. PF will generate strong Initial Sequence Numbers (ISNs) for packets matching this rule." So we have 2 machines generating ISNs for the same connection. Could this be the problem? SECOND Are the "flags S/SA" altq functions? Because, as I said before, the new firewall is FreeBSD GENERIC kernel with altq not compiled in. Yudhvir "I play with fire....walls" === _______________________________________________ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
