Re: Routing with Linux
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 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
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
--
Fraser Campbell <fraser@wehave.net> http://wehave.net/
Brampton, Ontario, Canada Linux 2.4.20 AuthenticAMD
Reply to: