I can understand that, provided you get everything configured first it should be no more than the time it takes to switch cables around just to forewarn you there will be a brief interruption when you make the switch for at least any connection where DNAT is involved even if the IP's don't change. The reason being that a network device performing DNAT is stateful (It needs to remember which active connection maps where), when the device performing the NAT changes is no longer has the state information from the existing device so each connection needs to be established again.
I find especially if there are a large number of actions or if it is
particularly critical to get it right first time it is worth before you
even start sitting down and writing your ruleset out in description form
first but do it so that each bullet point is one rule ie:
* All traffic with destination <IP> and port <port> in interface
<name> DNAT to <IP> on <port>
If you have something like that you can then go through an verify that
the rules in your shorewall configuration match, can be a bit much to be
useful as an IPtables rule comment but I find it can be a handy
reference to actually include them in the config files like:
# Rule 1: Accept TCP traffic from the internet zone destination
198.51.100.54 port 80.
?COMMENT Rule 1: Accept HTTP
ACCEPT net 198.51.100.54 tcp 80
Shorewall will completely ignore the # comment, the second one is added
to the rule and will show up in shorewall show etc makes it easy to
identify and find which rule generates what, especially if you number
them in order.
On 05/03/13 18:46, Ruth Ivimey-Cook wrote:
> Hi Matt
>> Sorry about the numbers there I added them as I was planning to write an
>> explanation of each then decided it probably wasn't required and forgot
>> to remove them. Oh well they serve as identifiers if anyone has any
>> further queries related to them.
> No problem, and what you've done here does I think help a lot.
>
> I will have to pull my courage together and actually do it now! (this is
> all on the one-and-only internet access for the site and there are
> external servers here, so being down at all is to be avoided... )
>
> Best regards,
> Ruth
>
>> On 04/03/13 23:09, Matt Joyce wrote:
>>> Hi Ruth, I will answer as best I can the parts I'm familiar with for
>>> you. I used to have a static /28 subnet with a prior ISP so I have
>>> experience with some of these points.
>>>
>>> With the default server your questions lead me to believe that you are
>>> presuming that you cannot keep on having shorewall take over the routers
>>> job here and preform the same job, every NAT rule is separate and can
>>> either specify an IP address or specify and IP and port such that you
>>> can easily have some odd ports go to one location and the remainder go
>>> to a default endpoint. The way to go about this in shorewall would be
>>> about the order you place the rules in the file, with a few exceptions
>>> noted in the documentation (like tcrules) iptables rules are first match
>>> wins, this means if you wrote your shorewall rules like this it would work.
>>>
>>> 1 DNAT net loc:IP1 tcp 25
>>> - &netiface
>>> 2 DNAT net loc:IP2 tcp 80
>>> - &netiface
>>> 3 DNAT net loc:DEFIP - -
>>> - &netiface
>>>
>>> You can use the IP instead of &ifname if you prefer it simply expands to
>>> the primary IP address on ifname which is useful if there is any chance
>>> that the IP address could change or just for readability. Do note the
>>> ordering is important when any of these rules match the packet is done
>>> so you need your most specific/highest priority rules first and lower
>>> priority wide defaults last.
>>>
>
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
