On Wednesday 05 March 2003 19:54, Fraser Campbell wrote: > On Wednesday 05 March 2003 11:20, Burner wrote: > > I would like to keep the public IP addresses on the servers if possible. > > Your servers can keep their public addresses if you wish, that should make > the job of firewalling a little easier (no masquerading to worry about). > > Let's say you had a public range 1.2.3.0/24, you might wish to allocate > 1.2.3.128/25 (the last half of the class C) to the firewall and machines > behind the firewall. > > Let's say your firewall had the IP 1.2.3.129, you would then have to add a > route like this to your Internet router something like this: > > route add -net 1.2.3.128 netmask 255.255.255.128 gw 1.2.3.129 > > Since your Internet router is most likely not Linux the above of course > won't be syntactically correct. > > If you don't want to set up a subnet within your router then you can simply > have the firewall respond to arp requests for those IP addresses that are > behind it. To respond to arp requests for addresses that are not your own > is called proxy arp (I think), you can achieve that with a command like > this: > > arp -s 1.2.3.135 00:80:80:80:80:80 -i eth3 pub > > This assumes a machine with the IP address 1.2.3.130 is in your DMZ, it > assumes that the your public interface is eth3 with a MAC address of > 00:80:80:80:80:80. > > > Maybe i should configure the linux router with all the external IP's on > > one NIC, and give the protected servers local IP addresses. then NAT the > > public IP/ports to the servers using iptables, this is a way to do it, > > but is it i good way? > > With either a proper subnet or proxy arp you can use public IPs in your > DMZ. Private IPs give you a lot more flexibility but at the expense of > complexity. FWIW, we almost always use private IPs in the DMZ.
I see your point here, i think it would be wise to choose the flexible solution, not that i need it right now, but as the load increases so does the need for flexibility. > > I have had problems with masquerading multiple IPs in that the masquerade > doesn't match the inbound IP. If you port forward using masquerading > (using ipvs/ipmasqadm/???) then the return traffic must also be > masqueraded. I have found that all return traffic is masqueraded to the > first IP on your public interface, instead of with the same IP as the > inbound traffic was masqueraded from. > > The only way to ensure that outbound traffic goes back out with the correct > IP is with iproute2. A rule such as this does the trick: > > ip rule from 192.168.1.135 lookup main map-to 1.2.3.135 i guess iptables will do the trick with somthing like this: iptables -t nat -A POSTROUTING -o eth3 -s 192.168.1.135 -j SNAT --to 1.2.3.135 iproute2 looks way more flexible than iptables though, is this flexibility at the cost of performance, or is it just a new wonderland for network admins? :) I realy do like what i learned about iproute2 so far. It seems to be worth reading the documentation in any case. > > Without the map-to argument, the traffic would just go out with the default > address (likely 1.2.3.129 in the case of my example). I haven't done > enough testing with netfilter to know if this problem is still existing in > the 2.4 kernel, my experience was from testing kernels up to 2.2.19. > > > I would be happy to recive any hints from someone who has done anything > > like this before. > > > > //Burner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
