On Tue, Apr 23, 2002 at 07:23:58PM +0200, Thilo Schulz wrote: [...] > I have a computer in my LAN with 2 ips (192.168.1.10 and 192.168.1.11), the > latter one created by "ip addr add" and users on that computer, and depending > on the uid of the created packets i want those to take another source address. > Of course, it should start with marking the packets with a simple iptables > rule: > > iptables -t mangle -A OUTPUT -m owner --uid-owner 1001 -j MARK --set-mark 1 [...] > The table as well as the route entry are correct, i am sure of this, for i > have tested removing the fwmark rule and instead added: > ip rule add to 192.168.1.4 table thilo > everything worked then as i have intended, and it showed me logged in from > 192.168.1.11 then. Are you sure it showed you as logged in from 192.168.1.11? I just tried the same setup here, and with either setup you describe, it always shows me as having logged in from the primary IP. In my case, I setup 192.168.1.1 and 192.168.1.2 and tried to connect to 192.168.1.5. In both cases above, it showed me as having logged in from 192.168.1.1. The counters are incrementing though, so marking is working. > Another problems checked too: I have enabled MARK based routing in the kernel > (policy routing, everything switched on ..) > > So I only can ask you on this mailing list - anyone got an idea of what > is/what i did wrong? Depending on what the results of your second setup above were (ip rule add to 192.168.1.4 table thilo), I have a theory... When you add a route that sets a src like: ip route add table <table> 192.168.1.0/24 src 192.168.1.11 dev eth0 The "src" doesn't specify the source IP to put in the packet (it's not network address translation, like SNAT in iptables), it just specifies which local source IP the routing mechanisms should use to determine where to route the packet. For example, I've got policy routing setup with FreeS/WAN on a gateway with an internal and external interface, where I do: # ip rule add table 1 prio 100 # ip route add table 1 <remoteLAN> dev ipsec0 src <localIP> This forces the box to route all packets to the remote LAN via the internal interface, rather than the external interface. However, the packets that show up at the other end don't contain a source IP of <localIP> from the table 1 route, rather they contain the source IP of the client machine that sent them. This led me to believe that the "src" option only adjusts the way the routing machinery in the kernel decides where and how to route the packet, but doesn't change/rewrite the source address in the packets themselves. This makes sense to me as well, because if setup routes for 192.168.1.4 through 192.168.1.11, and send packets from 192.168.1.10, they'll have a source address of 192.168.1.10, but get routed through the 192.168.1.11 interface (which is transparent at 192.168.1.4's end). If you really want the packets to look like they're coming from 192.168.1.11, why don't you just use iptables and SNAT them? -- Adrian Chung (adrian at enfusion-group dot com) http://www.enfusion-group.com/~adrian GPG Fingerprint: C620 C8EA 86BA 79CC 384C E7BE A10C 353B 919D 1A17 [toad.enfusion-group.com] up 34 days, 1:10, 17 users
