Hi all
I think I discovered a serious bug in the source-based routing /
demasquerading bug with the effect the packets just get thrown away. My
configuration is as follows:
- multiple LAN interfaces (eth0 - eth11)
- multiple routing tables: main, fazodies, local, fazat, maw, ...
- multiple default routes, one in each of the routing tables fazat and
maw
- policy routing with source-based selection of routing tables for
default
routes
- some external interfaces going to Internet providers
- some internal interfaces going to LANs
- pairs of external and internal interfaces that (logically) belong to
each
other
- the internal interfaces have both official and private IP addresses
What I need to do:
- traffic between LANs should be possible (official and private
addresses)
- traffic from LAN x to the Internet (default route) should go out on
external interface x
- traffic from LAN x from private addresses to the Internet (default
route)
should go out on external interface x, masqueraded as the address of
external
interface x
----------------
| Router lo | eth1 <---> Internet
provider 1
LAN 1 official addresses <---> eth2 | routing | eth1 <---> Internet
provider 1
LAN 1 private addresses <---> eth2 | masquerading | eth1 <---> Internet
provider 1
LAN 2 official addresses <---> eth4 | routing | eth3 <---> Internet
provider 2
LAN 2 private addresses <---> eth4 | masquerading | eth3 <---> Internet
provider 2
.... | |
----------------
example for 2 pairs of interfaces:
eth1: 212.52.195.10/30, going to Internet provider 1, gateway
212.52.195.9
eth2: 212.52.195.97/27, going to LAN 1
192.168.10.1/24
eth3: 212.52.195.6/30, going to Internet provider 2, gateway
212.52.195.5
eth4: 212.52.195.65/27, going to LAN 2
192.168.77.1/24
I use the commands:
.... setup of interfaces ....
ip rule add prio 1 table main
ip route add table fazat default via 212.52.195.9 src 212.52.195.10 dev
eth1
ip rule add prio 102 iif eth2 from 212.52.195.96/27 table fazat
ip rule add prio 202 iif eth2 from 192.168.10.0/24 nat 212.52.195.10
table fazat
ip route add table maw default via 212.52.195.5 src 212.52.195.6 dev
eth3
ip rule add prio 103 iif eth4 from 212.52.195.64/27 table maw
ip rule add prio 203 iif eth4 from 192.168.77.0/24 nat 212.52.195.6
table maw
ip rule add prio 32000 iif lo table fazat
ip route flush cache
The routing table "main" is not touched explicitely, it just contains
the routes to the directly connected networks. The source-based routing
works perfectly for official addresses that do not get translated and it
also works for masqueraded addresses going out on eth1. An example for
this:
Mar 26 20:33:03 firewall kernel: Packet log: input - eth2 PROTO=6
192.168.10.98:3175 207.134.168.2:80 L=40 S=0x10 I=5123 F=0x4000 T=128
(#1)
Mar 26 20:33:03 firewall kernel: Packet log: output - eth1 PROTO=6
212.52.195.10:61449 207.134.168.2:80 L=40 S=0x10 I=5123 F=0x4000 T=127
(#1)
Mar 26 20:33:03 firewall kernel: Packet log: input - eth1 PROTO=6
207.134.168.2:80 212.52.195.10:61449 L=1500 S=0x00 I=39291 F=0x4000
T=110 (#1)
Mar 26 20:33:03 firewall kernel: Packet log: output - eth2 PROTO=6
207.134.168.2:80 192.168.10.98:3175 L=1500 S=0x00 I=39291 F=0x4000 T=109
(#1)
However, it does not work for masqueraded addresses going out on eth3:
Mar 26 20:39:57 firewall kernel: Packet log: input - eth4 PROTO=17
192.168.77.66:53 140.78.2.62:53 L=64 S=0x00 I=54246 F=0x0000 T=128 (#1)
Mar 26 20:39:57 firewall kernel: Packet log: output - eth3 PROTO=17
212.52.195.6:61450 140.78.2.62:53 L=64 S=0x00 I=54246 F=0x0000 T=127
(#1)
Mar 26 20:39:57 firewall kernel: Packet log: input - eth3 PROTO=17
140.78.2.62:53 212.52.195.6:61450 L=163 S=0x00 I=18690 F=0x4000 T=244
(#1)
But then, the firewall does not send any packet out, it is just lost.
However, I can make it work for eth3 when I change
ip rule add prio 32000 iif lo table fazat
to
ip rule add prio 32000 iif lo table maw
But then, it does not work with eth1.
Why is the demasquerading dependent on the default route for packets
coming from the lo interface ? Has anybody an idea on this ? The next
thing that I want to do is to compile the kernel with
CONFIG_IP_MASQ_DEBUG to see if I can get more information on the
problem.
Please reply directly to me, I am not subscribed to the mailing lists.
greets,
Rene
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:18 EST