I''m new to Shorewall and having some difficulty switching the access
for a
newly assigned public IP block. This switch is from a class c to class a
block. The ISP has both blocks active on our connection to lesson the
disruption during the switch over.
We currently use Shorewall 3.2.4 and our setup is as follows.
Internet -> Firewall --- Lan
--- DMZ
Zones are:
net eth2
loc eth1
dmz eth0
I also have multiple virtual interfaces on eth2 using IP''s from the
public
block for DNAT connetions.
The first thing I did during was changed the virtual interface IP''s
used for
DNAT to IP''s in the new block. Everything here works as expected after
this
change.
The second change I made didn''t work out so well. We have two systems
in
the DMZ which use one to one NAT. I added two more entries to the list for
the new IPs so that when I had the DNS records changed it would translate
both the old and new IP while the switch made it to all DNS servers. I
never got to change the DNS records because through the night the firewall
stopped allowing connections to these systems. I removed the two entries and
everything started working again. Should this not work since it just
translates the address used from outside to the one I want on the inside?
The next thing I tried didn''t work either. I changed the main
interface IP
used for the net zone to one in the new IP block. This didn''t display
any
immediate problems either but I did find it strange that it would display
the only IP left on one of my virtual interfaces from the old class C block
when I would check the IP I was connecting from at dnsstuff. I figured that
this should be the new IP I had on eth2 for the net zone. This is another
case were through the night the access stopped working from outside again. I
changed the interface back and all worked as advertised.
I figure I''m missing something basic here but I can''t pin
point it. Could
someone please shed some light on this for me?
TIA
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Wed, Sep 26, 2007 at 03:49:16PM -0400, Dave Boltz wrote:> > I figure I''m missing something basic here but I can''t pin point it. Could > someone please shed some light on this for me? > TIAWithout any details on your configuration, helping you will be problematic at best. Please see: http://www.shorewall.net/support.htm#Guidelines Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Dave Boltz wrote:> I''m new to Shorewall and having some difficulty switching the access for > a newly assigned public IP block. This switch is from a class c to > class a block. The ISP has both blocks active on our connection to > lesson the disruption during the switch over. > > We currently use Shorewall 3.2.4 and our setup is as follows. > > Internet -> Firewall --- Lan > > --- DMZ > > Zones are: > > net eth2 > > loc eth1 > > dmz eth0 > > I also have multiple virtual interfaces on eth2 using IP''s from the > public block for DNAT connetions. > > The first thing I did during was changed the virtual interface IP''s used > for DNAT to IP''s in the new block. Everything here works as expected > after this change. > > The second change I made didn''t work out so well. We have two systems > in the DMZ which use one to one NAT. I added two more entries to the > list for the new IPs so that when I had the DNS records changed it > would translate both the old and new IP while the switch made it to all > DNS servers. I never got to change the DNS records because through the > night the firewall stopped allowing connections to these systems. I > removed the two entries and everything started working again. Should > this not work since it just translates the address used from outside to > the one I want on the inside?It depends. Since one-to-one NAT translates in both directions, whichever /etc/shorewall/nat entry is first will determine the outgoing SOURCE IP. If that is different from the IP address on which a request is sent, you can have problems with both SMTP and DNS servers.> > The next thing I tried didn''t work either. I changed the main interface > IP used for the net zone to one in the new IP block. This didn''t > display any immediate problems either but I did find it strange that it > would display the only IP left on one of my virtual interfaces from the > old class C block when I would check the IP I was connecting from at > dnsstuff. I figured that this should be the new IP I had on eth2 for > the net zone.That problem description is too vaque for me to comment. This is another case were through the night the access> stopped working from outside again. I changed the interface back and > all worked as advertised.As Roberto says, without details we can''t even hazard a guess as to what your problems are, let alone what the solutions might be. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On 9/26/07, Tom Eastep <teastep@shorewall.net> wrote:> > Dave Boltz wrote: > > I''m new to Shorewall and having some difficulty switching the access for > > a newly assigned public IP block. This switch is from a class c to > > class a block. The ISP has both blocks active on our connection to > > lesson the disruption during the switch over. > > > > We currently use Shorewall 3.2.4 and our setup is as follows. > > > > Internet -> Firewall --- Lan > > > > --- DMZ > > > > Zones are: > > > > net eth2 > > > > loc eth1 > > > > dmz eth0 > > > > I also have multiple virtual interfaces on eth2 using IP''s from the > > public block for DNAT connetions. > > > > The first thing I did during was changed the virtual interface IP''s used > > for DNAT to IP''s in the new block. Everything here works as expected > > after this change. > > > > The second change I made didn''t work out so well. We have two systems > > in the DMZ which use one to one NAT. I added two more entries to the > > list for the new IPs so that when I had the DNS records changed it > > would translate both the old and new IP while the switch made it to all > > DNS servers. I never got to change the DNS records because through the > > night the firewall stopped allowing connections to these systems. I > > removed the two entries and everything started working again. Should > > this not work since it just translates the address used from outside to > > the one I want on the inside? > > It depends. Since one-to-one NAT translates in both directions, whichever > /etc/shorewall/nat entry is first will determine the outgoing SOURCE IP. > If > that is different from the IP address on which a request is sent, you can > have problems with both SMTP and DNS servers.This could be my problem then. The two connections are a MX server and a Web server. I may have added the two entries above the existing ones. The only question with that is wouldn''t this take effect as soon as I applied the changes?> > > The next thing I tried didn''t work either. I changed the main interface > > IP used for the net zone to one in the new IP block. This didn''t > > display any immediate problems either but I did find it strange that it > > would display the only IP left on one of my virtual interfaces from the > > old class C block when I would check the IP I was connecting from at > > dnsstuff. I figured that this should be the new IP I had on eth2 for > > the net zone. > > That problem description is too vaque for me to comment. > > This is another case were through the night the access > > stopped working from outside again. I changed the interface back and > > all worked as advertised. > > As Roberto says, without details we can''t even hazard a guess as to what > your problems are, let alone what the solutions might beI guess you''re right. My fear is that I have to break the firewall putting our users out while I figure out what''s happening. Just a thought here... since this doesn''t happen at the time I make the change and restart shorewall it may have something to do with the routing cache. Mind you the when I revert the change it starts working immediately. Any thoughts on things I should do to make the problem show up strait away? This would make it much easier to debug my setup. .> > -Tom > -- > Tom Eastep \ Nothing is foolproof to a sufficiently talented fool > Shoreline, \ http://shorewall.net > Washington USA \ teastep@shorewall.net > PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > > >------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Wed, Sep 26, 2007 at 08:44:55PM -0400, Dave Boltz wrote:> Just a thought here... > since this doesn''t happen at the time I make the change and restart > shorewall it may have something to do with the routing cache. Mind you the > when I revert the change it starts working immediately. Any thoughts on > things I should do to make the problem show up strait away? This would make > it much easier to debug my setup.Down all the interfaces then raise them again. That will flush most of the caches. It is extremely unlikely that you have a caching problem; that only happens when you''re doing strange things, like assigning the same address to multiple hosts or swapping addresses between hosts. In any reasonably sane 1-to-1 arrangement, the kernel will clear out stale cache entries as you change the configuration. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/