Re: Secondary WAN

Bob Evans <ipcopu_list-za6GKHvPnsC+O/rFHDoEyJWNWR1az2d/Wmv/[email protected]>
Newsgroups gmane.comp.security.ipcop.user
Message-ID <[email protected]>
In article 
<CALgqCCmGBG6ZQW37bbrkaKisWjfn=Vrt2aF4wjVWE4zY_o0pqA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>, 
James Bewley <[email protected]> wrote
>We are fairly unique in that we have thousands of remote connections coming
>from telemetry terminals all over the world via mixture of GSM, SMS,
>Ethernet, VPN and Satellite among others.  These are sporadic in connecting
>and will take some time to 're-home' to a new ip range.

Ah now I understand why you want a period of overlap between the "two" 
WAN circuits :)

>The existing WAN consists of multiple lines but this is managed by another
>router one hop on from IPCop and the new WAN is similar.  So I only really
>need the multi WAN temporarily during the migration.
>
>I did have a go at iptables briefly but am a little rusty and didn't feel
>confident so I bought a second IPCop instance and have that running on the
>network alongside the original IPCop instance.  Both gateways are on the
>network and NATing into the various services so migration can be done over
>the long-term.

Yes I can see how that will work. The LAN-side servers will of course 
see one IPCop or the other as their gateway but if the important traffic 
is all inbound TCP connections from remote clients then all should be 
happy.

Incidentally if you ever do need to do some networking beyond what IPCop 
can manage easily, then the Mikrotik RouterBoard family is well worth a 
look.  The learning curve is a little steeper than for IPCop's GUI, but 
the management interface is not bad and you get a lot more "bang for 
your buck" than with the big name routers.

In regard to your overlap period, I'm assuming that no-one has been so 
crazy as to hard-code the server addresses into the remote clients and 
therefore the duration of your WAN changeover window will be governed by 
how quickly the new addresses percolate through the DNS system.

In which case I would recommend that, a couple of days prior to the 
switch-over, you minimise the cacheing of the old addresses by reducing 
the Time-To-Live values of the relevant A records in the DNS zone files 
of the domains concerned to maybe a few tens or hundreds of seconds.

That way the change will take effect very quickly and after it has all 
happened you can return the TTL values back to the "normal" 24 hours or 
so.

Hope it all goes smoothly,
-- 
Bob Evans

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
IPCop-user mailing list
[email protected]
Manage your subscription or unsubscribe
https://lists.sourceforge.net/lists/listinfo/ipcop-user
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.