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 
<CALgqCCnJYhVNHDPD8T05aduU5OdrxU1eeWYNnGbkR_e2iHACOQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>, 
James Bewley <[email protected]> wrote
>We have just had a new line fitted and we need to have both WANs active
>during the migration to the new line.

Why? The question is not intended in a flippant way but because I know 
that if one is on-site and are organised, it is possible to reconfigure 
a working IPCop for a different WAN connection and/or address subnet and 
bring things back up in just a few seconds.

I don't know your application of course but, if you can't accept a 
service interruption of say a minute or two outside of main business 
hours, then IPCop is probably not the appropriate tool.  And if 
continuous operation is so vitally necessary, why is there only one WAN 
circuit at present?

>The new WAN operates on a different subnet to the other and obviously 
>has a different gateway address.
>
>>From the console I wasn't able to configure a secondary RED interface even
>though I have a spare NIC available.
>
>I can add IP aliases from the WAN2 and IPCop appears to respond to pings
>for these but the forwarding rules do not work.  I guess traffic is coming
>in via WAN2 and outbound traffic is being routed out of WAN1.

If the two WAN circuits are from the same provider, they might be 
willing to accept packets on each connection if they carry the source 
address of the other one.  If the provider is less clueful or two 
separate providers are involved then that probably will not be an 
option.

A little Googling will show that there is at least one IPCop 2.x add-on 
to help you assign extra network interfaces via the web GUI.  However 
that doesn't solve your problem as the GUI does not offer any way to 
turn such an interface into an extra WAN port.

>Is there anyway I can solve this with IPCop or any custom rules/routes I
>need to add get this working?

Yes it can be done. But not via the GUI and you will need to polish your 
IPTables skills :)

I have done something similar with RouterBoards to bond multiple WAN 
circuits for bandwidth aggregation and automatic fail-over.  In 
principle you need to do three things: (a) mark incoming WAN packets 
according to which WAN port they arrive by, (b) selectively route / NAT 
packets according to the particular connections they relate to and the 
packet marks they carry and (c) devise some reliable means of monitoring 
the up state of each circuit so that you can automatically fail-over as 
necessary.

But if this for a once and for all switch-over then I would suggest that 
the amount of work involved is likely to be out of all proportion to the 
benefit received.

>Do I need a second IPCop instance?

I cannot see how that would avoid a service interruption. But having a 
second pre-configured box in situ and already running would mean that 
the perceived outage would be not much more than the time needed to swap 
the cables over.

One hint that might help avoid a few moments of panic immediately after 
a switch-over: When re-plugging equipment that is already in operation, 
don't forget that, even if the IP subnet address at the other end is 
unchanged, the MAC address will be different and so you still need ARP 
to do its thing!

-- 
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.