Re: [suse-security] same ip for two interfaces
that would cause more configuration issues on the servers in the dmz, right ???
Nope. Just set the default gateway to 10.0.0.1 and everything would work. My ISP for example uses 192.168.* and 10.* for basically all of it's routers/etc/etc, they all have a "Real" IP on the "external" interface (i.e. connection point), and clients like me have a "real" IP for our machines. Guess what? You're reading email sent from a server in this network =).
i mean default gw and ip-address of the server are supposed to be on the same net. so i had to add one more route to the default gateway ???
huh? not at all. No reason you can't have server with 1.2.3.4, 1.2.3.5, etc talking to 10.0.0.1 as their default gateway. Just make sure they know where 10.0.0.1 is, i.e.: route add -net 10.0.0.0 netmask 255.255.255.0 eth0 or route add -host 10.0.0.1 eth0 Another note: if your ISP was willing to play ball your firewall could use "non routed internal" IP's on all interfaces, the advantage would be you save a "Real" IP, and no external people can talk directly to the firewall. Prolly another strong reason my ISP does it on all the stuff (hard to attack something you can't route packets directly to).
am i right, not really sure !!
On an unrelated note: if I receive an out of office reply or annoying bounce from you (like volvo's full mailbox guy for example, or the broken mail account at a certain company) I will block your domain from my mailserver until a) I flush my rules in a few months or b) you contact me from another host and can show you've fixed it. I'm sick of getting bounces from security mailing lists. -Kurt
The whole thing is interesting from the academic standpoint. What would
happen with two interfaces of the same IP?
Roman.
--
- -
| Roman Drahtmüller
On Thu, 2 Nov 2000, Peter Lange wrote:
The whole thing is interesting from the academic standpoint. What would happen with two interfaces of the same IP?
Loadbalancing !?
Not automatically I think. How would you setup routing for two same IPs anyway? Robert -- Robert Casties --------------------- http://philoscience.unibe.ch/~casties History & Philosophy of Science Tel: +41/31/631-8505 Room: 216 Institute for Exact Sciences Sidlerstrasse 5, CH-3012 Bern Uni Bern (PGP key on homepage: D7 2B DE 64 2D 65 16 A0)
On Thu, 2 Nov 2000, Robert Casties wrote:
The whole thing is interesting from the academic standpoint. What would happen with two interfaces of the same IP?
Loadbalancing !?
Not automatically I think. How would you setup routing for two same IPs anyway?
Hmmm?? I don't really know wether or not ARP-Addr-Jumping will do the trick for incoming packets. But for outgoing packets you "simply" need to activate this "equal cost roitung" in the kernel and setup two routes over these two interfaces with the same cost. Regards Henning -- I have yet to see any problem, however complicated, which, when looked at in the right way, did not become still more complicated. -- Poul Anderson
hallo,
The whole thing is interesting from the academic standpoint. What would happen with two interfaces of the same IP?
i would say nothing interesting should happen. i think the other machines (say gateway) will send an initial arp request and will get an ip address + mac of one of the cards from the problem machine, maybe macs of both, but that does not matter. let's say the gateway got both macs and has its arp table like this: 1.2.3.4 xx:xx:xx:xx:xx:xx eth0 on machine under discussion 1.2.3.4 xx:xx:xx:xx:xx:xy eth1 on machine under discussion so when the gateway needs to talk to 1.2.3.4 machine it will check its arp table, find out that 1.2.3.4 has mac of xx:xx:xx:xx:xx:xx and start talking to that card without even looking at xx:xx:xx:xx:xx:xy. therefore, the second card will sit idle. i could be wrong here. the best way to find out is to run a tcpdump on both interfaces and see what mac addresses are flying on the wire. some other oses (like AIX) create an implicit route to its own subnet when an interface is brought up. but then, when it brings up the second interface and tries to establish an implicit route aix will not let you have a route to the same subnet since it already exists, thus adding route to its own subnet fails. therefore the second card will not even show up in the routing table. the above is true even for two cards on the same subnet. but aix is not linux... bye, -alexm
On 2 Nov 2000, at 8:40, alex medvedev wrote:
table, find out that 1.2.3.4 has mac of xx:xx:xx:xx:xx:xx and start talking to that card without even looking at xx:xx:xx:xx:xx:xy. therefore, the second card will sit idle.
Ok, what if I did this on one of my Sbus Sparcs? All the Interfaces have the same MAC (only one MAC per System). mike
Thomas Michael Wanka wrote:
Ok, what if I did this on one of my Sbus Sparcs? All the Interfaces have the same MAC (only one MAC per System).
There are two possibilties: 1.) use alternate pathing 2.) change the nvram setting to push the sparc to use different mac addrs at each NIC andy -- ------------------------------- mailto:Andreas.Tirok@beusen.de fon: +49 30 549932-37 fax: +49 30 549932-21
hi, On Thu, 2 Nov 2000, Thomas Michael Wanka wrote:
On 2 Nov 2000, at 8:40, alex medvedev wrote:
table, find out that 1.2.3.4 has mac of xx:xx:xx:xx:xx:xx and start talking to that card without even looking at xx:xx:xx:xx:xx:xy. therefore, the second card will sit idle.
Ok, what if I did this on one of my Sbus Sparcs? All the Interfaces have the same MAC (only one MAC per System).
i do not know much about sparc... is that an etherchannel? i think you need to have a special switch for that that round-robins between the ports participating in the etherchannel. os should also be aware of such a congregate. i am not sure how it works. bye, -alexm
The whole thing is interesting from the academic standpoint. What would happen with two interfaces of the same IP?
Its not academic from a system administrator's point of view, s/he'd get a headache :-) Depending on the *nix, it would work. For example, Linux would cope but AIX3 would not or a least SMIT would not let you do it. The real problem is that you have to sake such care in configuring your hosts that it becomes a disaster waiting to happen. For example: - You must specify all routing by device to ensure subnets are not assumed. - If the DMZ network is not a maskable block, you are in to a route per host. - Either all hosts on each of the identical interfaces must route to their own subnet via the firewall if they wish to talk to the other part of the subnet or the firewall must proxy arp for the hosts on the DMZ - Broadcasting will only occur on one of the interfaces -- maybe! There's probably a lot more but I hope that is enough to put you off. Here is a version that will work. Assigned address space assumed as 1.2.3.0/nn. Interfaces Red=1.2.3.1, DMZ=10.0.0.1, Green=10.0.1.1. DMZ_Hosts=10.0.0.0/24 plus alias on each host set to its assigned address. All that now needs to be configured is the routing in the firewall for each DMZ host. You also have a model that can be bolted down even tighter using switch technology or forcing all traffic via the firewall. Another option is to forget the aliassing and use one the address translation facilities. YMMV. John
hallo, On Thu, 2 Nov 2000, Kurt Seifried wrote:
huh? not at all. No reason you can't have server with 1.2.3.4, 1.2.3.5, etc talking to 10.0.0.1 as their default gateway. Just make sure they know where 10.0.0.1 is, i.e.:
route add -net 10.0.0.0 netmask 255.255.255.0 eth0
or
route add -host 10.0.0.1 eth0
i am not sure if you can have 10.0.0.1 serve as a default gateway to 1.2.3.4... what is your netmask going to be? 0.0.0.0? can you have a default gateway several hops away? thanks, -alexm
i am not sure if you can have 10.0.0.1 serve as a default gateway to 1.2.3.4... what is your netmask going to be? 0.0.0.0? can you have a default gateway several hops away?
You would add a f**king route for 10.0.0.1 or 10.0.0.0/255.255.255.0 network!. You people really need to get out of a rut, i.e. LAN's with C classes, there is MUCH more to life then that.
thanks,
-alexm
-Kurt
participants (9)
-
alex medvedev -
Andreas Tirok -
Henning Hucke -
John Trickey -
Kurt Seifried -
Peter Lange -
Robert Casties -
Roman Drahtmueller -
Thomas Michael Wanka