[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: routing based on source IP



Note that all the variables in my examples below (i.e. $eth0_ip) assume you will replace them with the real values or with variables that have the correct values.

Leonardo Boselli wrote:
> Question: Hov to route based oin sorce address ?
> System: host with 2.4.22 eth0 eth0:2 eth1 eth2 ippp0 ppp0 ppp1 ppp2
> port usage: eth0 is main port, with a public address on subnet a.b.c.0
> (that has a.b.c.1 as gateway)
> eth0:2 is a virtual port with a 172.16 address for private hosts (dhcp
> supply such addresses with our host as a gateway)

It's not always a great idea to have your public and private networks on the same ethernet port. Depending on the card, you may have serious performance issues, not to mention a potential security hole.

> eth1 is used to connect to a DSL modem to a different provider than
> a.b.c.0 [sorry, i do not trust neither one, so i feel better having two links
> on diferent ISP] and have a single public address.
> eth2 has 192.168.11.10/22 address and is used to connect to a local
> "untrusted" network (whewre everyone can plug his machine and get an
> address by dhcp)
> ippp0 is a dialin line ; with a fixed address from a.b.c.0
> of the 3 ppp [serial] ports two are used for dialin only, and have two more
> address in public range, the third is port used to conect to a different
> number and "offer" 192.168.8.10/22 as address.
> Requirements:
>  having a different routing for packets:
> 1. sourcing from the host itself (that runs apache-ssl squid and exim-4,
> and all these programs do no have problem in regognizing the sorcue of
> request ) except 5

I don't understand exactly what you're saying here, but if you just want to allow packets from the firewall/router, just create ACCEPT targets for OUTPUTs on each of the interfaces (iptables):

iptables -A OUTPUT -o eth0 -j ACCEPT
...

> 2.   coming from eth0 with addresses of a.b.c.0/24 with request to route
> should be honoured except that packets with certain ports as destination
> should not be routed. This is the difference i want: packets from the host
> itself, or from one of the addresses assigned to dialin ports should not
> firewalled !)

iptables -A INPUT -i eth0 -s a.b.c.0/24 -m multiport --dports ! #,#,# -j ACCEPT
(syntax on above may be a bit off)

> 3.   coming from eth0:0 whit address 172.16 (doing snat/dnat then roting
> according the resulting address ! that is if the masqueraded address is
> a.b.c.x then the packets should be routed as in 2, if the address is in
> 192.168.10.0 subnet should be routed as if come from eth2 with this
> address

I'm not sure you can create rules based upon virtual ports. You may have to go with interface eth0, source address 172.x.x.x\x.

> 4.  coming from eth1 only packets to that address.

iptables -A INPUT -i eth1 -d $eth1_ip -j ACCEPT

> 5. packets from local host sent to certains subnets (static list) should be
> routed via eth1 osing the corresponding address, NO routing should
> occour between eth1 and the other ports
> 6. packets form eth2 should be routed only to eth0:0 (that is 172.16. )
> and to selected hosts in a.b.c.8/29
> 7.  packet from dialin ports should be plainly routed if the address is
> a.b.c.x , if the address is 192.168.8.10 the routing should be same as 6,
> in both cases however NO firefalling should be done on these
> connections, so a remote [but locally authenticated] user can request any
> port.

I believe you're going to want to take a look at iproute2 (and other aspects of advanced routing):
http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/index.html

Specifically, there is an example for source policy routing (which interface gets the masquaraded/forwarded packet happens outside of iptables):
http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.simple.html

> 8. of course: if one of the dialin addresses assigned to the 4 ports of this > host appear on one of the ethernet ports should not be routed (it would be > nice to have a bucket of chilled water trown to the one that did the misfact
> ... but i fear it cannot be done at kernel level )

You may try submitting a bug report for this.  ;)

mickey



Reply to: