Two Nics setup with no bridging but still seem to bridge??
I'm trying to setup a Centos box to act as a backup server for our intranet between stores. I have two interfaces in it, the first one is currently connected to my local network and is using dhcp to get its ip address and such, the second one is set to a static ip address and is connected to an independent network that just has a DigiBoard Portserver hooked to it and no connection to the regular network. What I am doing is using ssh to portforward the telnet port on this box to the main server so when you telnet into the box from the second interface using the portserver you get connected to the main server. I plan on using this over DSL lines as a backup when our main dervice goes out to allow the portservers at the remote locations to seemlessly connect to the main server by just moving the network cable from the local net to the backup server. My problem is that when I have the everything working I am able to ping the second interface ip address from the normal network even though the secondary card does not in anyway externally connect to the network, this is a problem. Eventually I want to duplicate the main server address so that the normal portservers and other terminals on the remote site will not have to be reconfigured to access the backup server. All I want is to be able to tell the managers is to switch a cable while the main connection is down and not have to manage a bunch of config files to get the store back up. Right now if I duplicate the main server ip address and it is accessible through the first interface I'm guessing I'll see all kinds of problems relating to duplicate ip addresses on the network. I've tried some routing and iptable stuff but I'm not real familiar with either so I had no luck. Is there someway to block the internal connection between the two interfaces so the only thing that sees the duplicate ip address is the second interface??
Ongoing problems with dual nics and duplicate ip address
Well I have the initial system up and running with a normal ip address on the interface that connects to the local network and a duplicate address, of the main server, on the interface that only connects to the portserver. I can now log into the main server with the portserver connected to either through the second interface or hooking it directly to the local network meaning to the portserver the change in interfaces doesn't matter anymore. I'm using an iptable entry to drop all inputs to the normal interface that try to go to the main server with an entry like this:
iptables -I INPUT -i eth0 -d 220.127.116.11 -j DROP
18.104.22.168 is the main server address and eth0 is the interface connected to the local network. This seems to stop any attempts from the local network to access the second interface, eth1, with the duplicate ip address of 22.214.171.124 through the first interface so I don't have problems with confusing anything on the localnet trying to log into the main server.
I also had to add a route using:
route add 126.96.36.199 gw 188.8.131.52
To link the second interface up to the portserver, 184.108.40.206.
All I have to do then is ssh into the main server and port forward the telnet port of the backup server to it. Well not quite, when I try to ssh into the main server from the backup server it is still confused and tries to go to the eth1 card and fails, this wont be a problem when I have the backup server at the remote store since it will be logging into our web address instead of the local 220.127.116.11. I just pointed a temp ssh to another machine on the local net like this:
ssh -L 18.104.22.168:23:22.214.171.124:23 126.96.36.199
So all seems to be well and good.....except...... We seem to be having speed issues with PCs running term emulators and I'm wondering if something is still leeking through the iptable or whatever that is confusing the local net between the main server and the backup server.