Hi Yudhvir, mehma sarja wrote on Sun, May 17, 2009 at 01:27:12PM -0700:
> 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. Usually, you first define your problem, then choose apropriate software, then apropriate hardware to run the software. Getting stuck with weird hardware that cannot run OpenBSD and then switching to FreeBSD just to run pf(4) does not sound all that convincing. > c. So, one test is to put these two firewalls in tandem - just for testing. Just ripping out the old one when you are satisfied with the new one probably won't work, anyway. I guess you will at least need to adjust part of the rules and part of the routing tables. And you will be back to testing after doing these adjustments. > 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? I can't say; i'm not running networks so important that a month of testing is required before updating the firewall. Then again, if you can afford to run with a single firewall (no CARP, no redundancy) and if you can afford to run four-year-old unmaintained software, your needs are probably not that demanding, either. So testing for a month in a complicated way is probably way out of proportion, and you might be better off just testing the new device until you are reasonably sure it's ready, then announce a few hours of scheduled downtime in the night on a weekend, rip the old one out, put the new one in and fix any remaining bugs in place. Regarding your pfctl dumps: Remote diagnosis is very difficult, and with partial pfctl dumps and without interface and IP assignment info almost impossible. It's much easier in place. Look at tcpdump(8) output on the relevant interfaces and pflog(4) devices, compare to your rule sets and figure out where exactly the packets get blocked and why. I'm not volunteering to debug your pf(4) setup on FreeBSD, even if you would send complete configuration information, sorry... ;-) Yours, Ingo
