Re: Routing with Linux
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
Reply to: