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