[Shorewall-newbies] Migrating a firewall from old hardware to new

Tom Eastep teastep at shorewall.net
Sat Mar 6 16:01:55 PST 2004

On Sat, 6 Mar 2004, Chris Evans wrote:

> On 6 Mar 2004 at 14:01, Tom Eastep wrote:
> > > So my first question (yes, I have been through the sequence of
> > > changes in the FAQ) is:
> > >
> > > what is likely to have be changed in my config files?
> >
> > Did  you look at the Upgrade Issues page
> > (http://shorewall.net/upgrade_issues.htm)? That would be the best
> > source of information about what the pitfalls of this upgrade would
> > be.
> I did, had the distinct impression from comments elsewhere in your
> documentation that there were changes that weren't included there.  I
> realise that seems unlikely and I'll go through it again and see if I
> can put my finger on the particular things that I thought weren't
> there.

It's possible of course but any time that I make an incompatible change, I
hope that I have documented it on that page.

> > If the BT device is truly a router then cycling the power on it should
> > cause it to refresh it's arp cache.
> What's the alternative to a router and can you point me to anything
> that might help me establish this as I have the distinct impression
> that debugging a transfer if you can't get the arp cache issue sorted
> might be difficult and this is a firewall protecting a running system
> so I can't afford for it to be offline for hours.

If the device itself has an IP address which is also the default gateway
for your systems then it is probably a router. Otherwise, it is probably
some sort of bridge.

Both the proxy arp and NAT documentation give instructions for determining
if the upstream ARP cache is the problem.

> > The crawling access to the dmz from the local network would have
> > nothing to do with arp caches.
> Thanks, that was my impression.
> > > And my final question is:
> > > Am I better ditching proxyarp and going for SNAT/DNAT combination
> > > for both loc and the dmz?
> >
> > No. Crawling access between two local networks is usually a driver or
> > hardware issue (although mis-matched MTUs can also contribute).
> I don't think it's hardware or drivers as I can use all three of the
> ports on the machine fine in standalone fashion.

Does the slow access only occur on new connection establishment? If so, it
is probably a DNS problem. Is your kernel belching Shorewall messages when
you see this problem?

MTU = Maximum Transmission Unit

If you "ip link ls", you can see the MTU of all of your net devices.
All of the ethernet devices should have MTU=1500.

> More generally (repeat _NO_ rush on these questions) would you
> recommend ditching proxyarp and, if so, how/why?  Again, I had the
> impression from one thing on your site that you were recommending
> moving away from proxyarp (problems with collisions with
> FreeSWAN/tunnelling?) but another thing seemed to suggest there were
> no problems other than the cache issue.

Unless you absolutely have to use IPSEC for compatibility reasons, I would
use ANY other method. The 2.4 FreeS/Wan implementation has the Proxy ARP
problem (among others) and the 2.6 implementation isn't currently well
supported by Netfilter. Even when the Netfilter code is available, it is
unlikely that IPSEC under 2.6 will never be as well supported by Shorewall
as the other tunnel types.

Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep at shorewall.net

More information about the Shorewall-newbies mailing list