Hey everyone! I came across this link today: http://www.sjdjweis.com/linux/proxyarp/ Which I thought was very interesting. But I don''t quite understand how, or what effect assigning the same IP address to both the left and right side interfaces of the pseudo-bridge has. In the article, the author describes a mechanism for being able to shape/filter traffic to an entire ISP assigned subnet. Basically, use proxy arp, assign the same ISP IP to both interfaces on the router, and use iproute2 to create routes to the router on one interface, and the rest of the network on the other. It''s almost identical to the Proxy-Arp/Pseudo Bridge part of the LARTC HOWTO. Except that I''m confused as to how the kernel deals with the fact that both interfaces have the same IP address. I guess logically it doesn''t matter to the kernel, because the routes clearly delineate which interface to send packets to, proxy-arp connects the two LANs, and both interfaces have different MAC addresses. It just seems wrong. :) -- Adrian Chung (adrian at enfusion-group dot com) http://www.enfusion-group.com/~adrian GPG Fingerprint: C620 C8EA 86BA 79CC 384C E7BE A10C 353B 919D 1A17 [toad.enfusion-group.com] up 1:44, 1 user, load average: 0.00
On Wed, Feb 13, 2002 at 10:35:15AM -0500, Adrian Chung wrote:> Hey everyone! I came across this link today: > > http://www.sjdjweis.com/linux/proxyarp/ > > Which I thought was very interesting. But I don''t quite understand > how, or what effect assigning the same IP address to both the left and > right side interfaces of the pseudo-bridge has. > > In the article, the author describes a mechanism for being able to > shape/filter traffic to an entire ISP assigned subnet. > > Basically, use proxy arp, assign the same ISP IP to both interfaces on > the router, and use iproute2 to create routes to the router on one > interface, and the rest of the network on the other.It does not matter which ip addresses you asign to which interfaces. You can also assing the official ip to lo.> It''s almost identical to the Proxy-Arp/Pseudo Bridge part of the LARTC > HOWTO. > > Except that I''m confused as to how the kernel deals with the fact that > both interfaces have the same IP address.The kernel sees one IP address, and two nics, with each having some part of a network directly attached to it.> I guess logically it doesn''t matter to the kernel, because the routes > clearly delineate which interface to send packets to, proxy-arp > connects the two LANs, and both interfaces have different MAC > addresses.Yep.> It just seems wrong. :)Nope. If you think about it: it is CLEAN! I''ve attached an e-mail which should give some more examples, and a copy of the mail I send to the maintainer of that site. (Eh, the update to the last mail: I tested it, and it works.) Some advice, eh to everybody: Really forget about route and ifconfig, try to switch to the iproute utility... -- <ard@telegraafnet.nl> Telegraaf Elektronische Media http://wwwijzer.nl http://leerquoten.monster.org/ http://www.faqs.org/rfcs/rfc1855.html Let your government know you value your freedom. Sign the petition: http://petition.eurolinux.org/
On Wed, Feb 13, 2002 at 04:52:09PM +0100, Ard van Breemen wrote:> On Wed, Feb 13, 2002 at 10:35:15AM -0500, Adrian Chung wrote:[...]> > Except that I''m confused as to how the kernel deals with the fact that > > both interfaces have the same IP address. > The kernel sees one IP address, and two nics, with each having some part > of a network directly attached to it. > > > I guess logically it doesn''t matter to the kernel, because the routes > > clearly delineate which interface to send packets to, proxy-arp > > connects the two LANs, and both interfaces have different MAC > > addresses. > Yep. > > It just seems wrong. :) > Nope. > If you think about it: it is CLEAN!You''re definitely right about that. It''s a *very* cool solution, I''d been looking for a way to do this. [...]> Another thing I am now busy to find out (I am not sure if this also > works on 2.2, but I have no reason to believe it does not work): > > ip link set up dev eth0 > ip addr add 127.0.0.1/32 dev eth0 > echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp > ip link set up dev eth1 > ip addr add 127.0.0.1/32 dev eth1 > echo 1 > /proc/sys/net/ipv4/conf/eth1/proxy_arp > ip route add x.x.x.96/28 dev eth0 > ip route add x.x.x.97/32 dev eth1 > > The theory behind it: the IP protocol driver needs to be bound to the > device. This is done by giving any (bogus) ip address to an interface. > Only after the IP protocol driver is bound to the interface you can use > it for IP. > /proc/sys/net/ipv4/conf will only show interfaces bound to the IP > protocol... :) > > Of course: you cannot reach the firewall, and the firewall can''t reach > you. You need a non-bogus ip address for that... (Hmmmm: ssh 127.0.0.1 > .. Hah! I hacked the firewall.... shutdown -h now ... Uh? ;) )Is this for real? So you bind 127.0.0.1 to both eth0 and eth1, not using an ISP assigned IP at all on the bridging box, and you''d still be able to route from the ISP''s network through to machines on the ISP assigned network? That''s way too neat. :) Have you tried this under 2.4? -- Adrian Chung (adrian at enfusion-group dot com) http://www.enfusion-group.com/~adrian GPG Fingerprint: C620 C8EA 86BA 79CC 384C E7BE A10C 353B 919D 1A17 [toad.enfusion-group.com] up 2:11, 1 user, load average: 0.00
On Wed, Feb 13, 2002 at 11:00:35AM -0500, Adrian Chung wrote:> On Wed, Feb 13, 2002 at 04:52:09PM +0100, Ard van Breemen wrote: > > The theory behind it: the IP protocol driver needs to be bound to the > > device. This is done by giving any (bogus) ip address to an interface. > > Only after the IP protocol driver is bound to the interface you can use > > it for IP. > > /proc/sys/net/ipv4/conf will only show interfaces bound to the IP > > protocol... :) > > > > Of course: you cannot reach the firewall, and the firewall can''t reach > > you. You need a non-bogus ip address for that... (Hmmmm: ssh 127.0.0.1 > > .. Hah! I hacked the firewall.... shutdown -h now ... Uh? ;) ) > Is this for real? So you bind 127.0.0.1 to both eth0 and eth1, not > using an ISP assigned IP at all on the bridging box, and you''d still > be able to route from the ISP''s network through to machines on the ISP > assigned network?Be careful however, you don''t want to send icmp_host_unreachables with source ip 127.0.0.1, I don''t think they get far. Anyway, 127.0.0.1 is as far as I know a special adres, also for the kernel. I haven''t experimented with that... If you want to have any sane outgoing source ip addresses, you also have to set the default source ip for the outgoing routes. -- <ard@telegraafnet.nl> Telegraaf Elektronische Media http://wwwijzer.nl http://leerquoten.monster.org/ http://www.faqs.org/rfcs/rfc1855.html Let your government know you value your freedom. Sign the petition: http://petition.eurolinux.org/
On Wed, Feb 13, 2002 at 05:07:35PM +0100, Ard van Breemen wrote:> On Wed, Feb 13, 2002 at 11:00:35AM -0500, Adrian Chung wrote:[...]> > Is this for real? So you bind 127.0.0.1 to both eth0 and eth1, not > > using an ISP assigned IP at all on the bridging box, and you''d still > > be able to route from the ISP''s network through to machines on the ISP > > assigned network? > Be careful however, you don''t want to send icmp_host_unreachables with > source ip 127.0.0.1, I don''t think they get far. > Anyway, 127.0.0.1 is as far as I know a special adres, also for the > kernel. I haven''t experimented with that... > If you want to have any sane outgoing source ip addresses, you also > have to set the default source ip for the outgoing routes.True enough... However, in my case anyways, it''s not an issue. I already have a box that''s using an ISP assigned IP as a gateway, but using aspects of the above solutions, I can now have all my DMZ servers funnelled through the one machine. That means that traffic control/shaping and bandwidth monitoring should become real easy, as it means one access point into/out of the network, but still with IP assigned IPs on the DMZ machines. Sorry if this is not news to anyone else, it''s an amazing revelation to me. :) -- Adrian Chung (adrian at enfusion-group dot com) http://www.enfusion-group.com/~adrian GPG Fingerprint: C620 C8EA 86BA 79CC 384C E7BE A10C 353B 919D 1A17 [toad.enfusion-group.com] up 2:24, 1 user, load average: 0.00