I am currently using shorewall on leaf-bering. I have set it up with keepalived to create a high availabilty firewall cluster. I have an odd question in regards to shorewall. Currently in production I have keepalived controlling shorewall starts and stops. If I remove this and leave shorewall running on the backup firewall, will I run into any problems with having the nat tables built out and the rule sets up and running? The rules sets allow the two firewalls to talk explicity via vrrp, and since keepalived actually controls the virtual IP addresses it sends out gratuitious arps when it takes over. So even though both boxes have the nat tables built out only the one that has sent out the garps is actually listening on those IPs. Does leaving the nat tables built out like that on a hot spare open up any potential security holes? IE is this a ok, or should I run routestopped to unload the nat tables and set the rule sets to routestopped?
On Wed, 2003-10-29 at 12:42, Charles Holbrook wrote:> I am currently using shorewall on leaf-bering. I have set it up with > keepalived to create a high availabilty firewall cluster. I have an odd > question in regards to shorewall. Currently in production I have > keepalived controlling shorewall starts and stops. If I remove this and > leave shorewall running on the backup firewall, will I run into any > problems with having the nat tables built out and the rule sets up and > running? The rules sets allow the two firewalls to talk explicity via > vrrp, and since keepalived actually controls the virtual IP addresses it > sends out gratuitious arps when it takes over. So even though both > boxes have the nat tables built out only the one that has sent out the > garps is actually listening on those IPs. > > Does leaving the nat tables built out like that on a hot spare open up > any potential security holes? IE is this a ok, or should I run > routestopped to unload the nat tables and set the rule sets to > routestopped?I don''t see a potential for security holes. You will probably need to configure Shorewall in such a way that it doesn''t interrogate the current IP configuration when it is starting since I assume that the IP config on the backup is incomplete until takeover. a) Don''t specify ''detect'' in /etc/shorewall/interfaces b) Don''t place the name of an interface in the second column of /etc/shorewall/masq entries. c) ... The documentation is explicit where there is a requirement to have interfaces configured and started before Shorewall can start when a given option is used. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Does detect in the /etc/shorewall/interfaces file do anything else besides finding the broadcast address? The reason I ask is all the virtual IP addresses getting built up are from the same CIDR block of IP addresses so broadcast is the same for all of them. And nothing is actually being done in the /etc/shorewall/masq file, it''s all taking place in the /etc/shorewall/nat file.> I don''t see a potential for security holes. You will probably need to > configure Shorewall in such a way that it doesn''t interrogate the > current IP configuration when it is starting since I assume that the IP > config on the backup is incomplete until takeover. > > a) Don''t specify ''detect'' in /etc/shorewall/interfaces > b) Don''t place the name of an interface in the second column of > /etc/shorewall/masq entries. > c) ... > > The documentation is explicit where there is a requirement to have > interfaces configured and started before Shorewall can start when a > given option is used. > > -Tom
On Wed, 2003-10-29 at 13:25, Charles Holbrook wrote:> Does detect in the /etc/shorewall/interfaces file do anything else > besides finding the broadcast address? The reason I ask is all the > virtual IP addresses getting built up are from the same CIDR block of IP > addresses so broadcast is the same for all of them. >All ''detect'' does is look for broadcast addresses. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Sorry to flood the mailing list today, I sent that last message off a little too quickly. One more question. Is there any chance of a nat entry referencing a nonexistant IP address getting expired by the kernel?> I don''t see a potential for security holes. You will probably need to > configure Shorewall in such a way that it doesn''t interrogate the > current IP configuration when it is starting since I assume that the IP > config on the backup is incomplete until takeover. > > a) Don''t specify ''detect'' in /etc/shorewall/interfaces > b) Don''t place the name of an interface in the second column of > /etc/shorewall/masq entries. > c) ... > > The documentation is explicit where there is a requirement to have > interfaces configured and started before Shorewall can start when a > given option is used. > > -Tom
On Wed, 2003-10-29 at 13:29, Charles Holbrook wrote:> Sorry to flood the mailing list today, I sent that last message off a > little too quickly. > > One more question. Is there any chance of a nat entry referencing a > nonexistant IP address getting expired by the kernel? >No. Connection tracking entries will eventually time out but NAT is specified by netfilter rules which are static. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net