On Thu, Apr 30, 2015 at 2:14 PM, francis picabia <fpica...@gmail.com> wrote: > We have a subnet running our legacy and primary DNS server > where it remains as the last system on that subnet. > Many things are pointing to that IP in resolv.conf, etc., > > We want to put the DNS server on the new subnet with all > the other systems, to simply configuration on the > new Fortinet firewall. > > It seemed a good solution would be to add a new IP to the > legacy system so it would be on two subnets, and adjust > named.conf so it was listening on both IPs. Later we could > update the multiple external settings pointing to the legacy subnet > and eventually take it down. > > After the second IP is brought up, we have something like this: > > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use Iface > XXX.YYY.2.0 * 255.255.255.0 U 0 0 0 eth0 > XXX.YYY.200.0 * 255.255.248.0 U 0 0 0 eth1 > link-local * 255.255.0.0 U 1002 0 0 eth0 > link-local * 255.255.0.0 U 1003 0 0 eth1 > default dyna2-1.mydom 0.0.0.0 UG 0 0 0 eth0 > > named is able to answer on either it's subnet 2 or subnet 200 address. > However, systems on subnet 200 which have the XXX.YYY.2.ZZ address > in the resolv.conf are timing out. > > If I try to ping the 2.ZZ address from a subnet 200 system, it fails. > I think it is because the packet arrives at the 2.ZZ address, and > it routes it through eth1 to get back to the subnet 200 destination. > The remote subnet 200 system thinks the packet is spoofed since > the answer came back from a IP different than it was sent to. > > Problems were restored simply by taking down eth1 for the time being. > > Is there an easy way to "make TCP/IP answer back on the same > interface it was listening on when a packet is received"? > > I've seen articles mentioning multi-homing and balancing, but that > doesn't seem to fit what we are looking for.
I think I found a blog that explains a solution with ip route commands in simple terms. https://kindlund.wordpress.com/2007/11/19/configuring-multiple-default-routes-in-linux/ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ca+akb6hakx4opqr2-fnmsdglbfgaomzl_+todhdgqekho-x...@mail.gmail.com
