RE: Multiple routes by uid-owner

RE: Multiple routes by uid-owner

[CJ East]

> -----Original Message-----
> From: " George Vieira " (via GeckoMail)
> [mailto:return-bec365195104-georgev-.-citadelcomputer.com.au@g
> eckomail.o
> rg]
> Sent: Monday, 14 July 2003 7:54 AM
> Subject: RE: Multiple routes by uid-owner
> 
> 
> --------------------------------------------------------------
> ------------
> This mail was received via GeckoMail.org alias 
> bec365195104@geckomail.org
> --------------------------------------------------------------
> ------------
> 
> Can you LOG all dropped packets, are you setting DROP as the 
> default for INPUT?

INPUT's policy is ACCEPT. 
Adding a LOG target to this chain does not shed any light- incoming
packets visible to tcpdump on the ppp interface *do not* enter the INPUT
chain. 

But it was a good thing to check, so thanks :D 

Yeah, owner id info is only available on the machine itself; but that's
all i need (I'm not forwarding packets or anything) 

The problem still stands-- why are correctly addressed incoming packets
visible to tcpdump but not to netfilter?  




> 
> Thanks,
> ____________________________________________
> George Vieira
> Systems Manager
> georgev@citadelcomputer.com.au
> 
> Citadel Computer Systems Pty Ltd
> http://www.citadelcomputer.com.au
> 
> Phone   : +61 2 9955 2644
> HelpDesk: +61 2 9955 2698
>  
> 
> -----Original Message-----
> From: CJ East [mailto:bec365195104@geckomail.org]
> Sent: Thursday, July 10, 2003 5:45 PM
> To: netfilter@lists.netfilter.org
> Subject: Multiple routes by uid-owner
> 
> 
> Hi, 
> 
> I'm currently trying to test several independent internet links. 
> 
> To do this, I instantiate two or more interfaces, which I aim to allow
> to route packets as though two separate machines were each 
> independently
> connected to the internet, and independently downloading some 
> file using
> http. 
> 
> - I run wget http://www.google.com with uid=500
> - I run wget http://www.google.com with uid=501 
> 
> - I set up using iptables; 
> chain OUTPUT
>  MARK all -- anywhere    anywhere  OWNER UID match 500 MARK set 0x1
>  MARK all -- anywhere    anywhere  OWNER UID match 501 MARK set 0x2
> 
> 
> - I set up using ip; 
> 
> ip rule add fwmark 1 table link1
> ip rule add fwmark 2 table link2 
> ip route add default dev ppp0 table link1
> ip route add default dev ppp1 table link2
> 
> - This all works more-or-less correctly.  
> Now, running wget and tcpdump reveals a DNS lookup going out on the
> correct interface, depending of course which userid is running. 
> 
> Notably, the SOURCE address isn't that of the PPP interface, it's of
> another (ethernet) interface in the machine.  Now, for profiling the
> connection, this is clearly unacceptable (Packets need to come back on
> the interface they were sent!)  Now, IIUC, an application can bind to
> any given source address-- but this is a bad idea in my case, since it
> requires each application be aware of its environment-- fine 
> if my test
> is ALWAYS wget (since I have the source), but bad generally. 
> 
> So, I've turned to SNAT, which I'm abusing to switch the source IP
> address to that of the ppp interface on the way out.  
> 
> A la, 
> 
> iptables -t nat -A POSTROUTING -o ppp0 -j SNAT --to-source x.x.x.x 
> 
> This certainly fixes the issue of errant source address, but now, a
> totally different problem..... Packets coming IN off the ppp interface
> (now bearing the correct address) don't appear to make it to the
> application! :( 
> 
> I had no idea what was going on, but suffice to say started messing
> around with the PREROUTING table enough to notice that these returning
> packets don't seem to traverse that hook either; they must be dropped
> somewhere in the kernel, however I'm not sure where or why.  
> I had been
> thinking that a corresponding DNAT rule (as crude as it must sound)
> would be a quick-and-dirty solution, but since the packets don't enter
> that chain.. Well, it's a non-starter :( 
> 
> Why are the packets dropped?   The requests are sent out over the same
> interface on which they are received (Which is a noted caveat for
> netfilter).  
> 
> 
> 
> 
> 
> 
> 
> 
> 

Re: Multiple routes by uid-owner

[Carlo Pires]

CJ East wrote:

>>-----Original Message-----
>>From: " George Vieira " (via GeckoMail)
>>[mailto:return-bec365195104-georgev-.-citadelcomputer.com.au@g
>>eckomail.o
>>rg]
>>Sent: Monday, 14 July 2003 7:54 AM
>>Subject: RE: Multiple routes by uid-owner
>>
>>
>>--------------------------------------------------------------
>>------------
>>This mail was received via GeckoMail.org alias 
>>bec365195104@geckomail.org
>>--------------------------------------------------------------
>>------------
>>
>>Can you LOG all dropped packets, are you setting DROP as the 
>>default for INPUT?
>>    
>>
>
>INPUT's policy is ACCEPT. 
>Adding a LOG target to this chain does not shed any light- incoming
>packets visible to tcpdump on the ppp interface *do not* enter the INPUT
>chain. 
>
>But it was a good thing to check, so thanks :D 
>
>Yeah, owner id info is only available on the machine itself; but that's
>all i need (I'm not forwarding packets or anything) 
>
>The problem still stands-- why are correctly addressed incoming packets
>visible to tcpdump but not to netfilter?  
>
>
>
>
>  
>
>>Thanks,
>>____________________________________________
>>George Vieira
>>Systems Manager
>>georgev@citadelcomputer.com.au
>>
>>Citadel Computer Systems Pty Ltd
>>http://www.citadelcomputer.com.au
>>
>>Phone   : +61 2 9955 2644
>>HelpDesk: +61 2 9955 2698
>> 
>>
>>-----Original Message-----
>>From: CJ East [mailto:bec365195104@geckomail.org]
>>Sent: Thursday, July 10, 2003 5:45 PM
>>To: netfilter@lists.netfilter.org
>>Subject: Multiple routes by uid-owner
>>
>>
>>Hi, 
>>
>>I'm currently trying to test several independent internet links. 
>>
>>To do this, I instantiate two or more interfaces, which I aim to allow
>>to route packets as though two separate machines were each 
>>independently
>>connected to the internet, and independently downloading some 
>>file using
>>http. 
>>
>>- I run wget http://www.google.com with uid=500
>>- I run wget http://www.google.com with uid=501 
>>
>>- I set up using iptables; 
>>chain OUTPUT
>> MARK all -- anywhere    anywhere  OWNER UID match 500 MARK set 0x1
>> MARK all -- anywhere    anywhere  OWNER UID match 501 MARK set 0x2
>>
>>
>>- I set up using ip; 
>>
>>ip rule add fwmark 1 table link1
>>ip rule add fwmark 2 table link2 
>>ip route add default dev ppp0 table link1
>>ip route add default dev ppp1 table link2
>>
>>- This all works more-or-less correctly.  
>>Now, running wget and tcpdump reveals a DNS lookup going out on the
>>correct interface, depending of course which userid is running. 
>>
>>Notably, the SOURCE address isn't that of the PPP interface, it's of
>>another (ethernet) interface in the machine.  Now, for profiling the
>>connection, this is clearly unacceptable (Packets need to come back on
>>the interface they were sent!)  Now, IIUC, an application can bind to
>>any given source address-- but this is a bad idea in my case, since it
>>requires each application be aware of its environment-- fine 
>>if my test
>>is ALWAYS wget (since I have the source), but bad generally. 
>>
>>So, I've turned to SNAT, which I'm abusing to switch the source IP
>>address to that of the ppp interface on the way out.  
>>
>>A la, 
>>
>>iptables -t nat -A POSTROUTING -o ppp0 -j SNAT --to-source x.x.x.x 
>>
>>This certainly fixes the issue of errant source address, but now, a
>>totally different problem..... Packets coming IN off the ppp interface
>>(now bearing the correct address) don't appear to make it to the
>>application! :( 
>>
>>I had no idea what was going on, but suffice to say started messing
>>around with the PREROUTING table enough to notice that these returning
>>packets don't seem to traverse that hook either; they must be dropped
>>somewhere in the kernel, however I'm not sure where or why.  
>>I had been
>>thinking that a corresponding DNAT rule (as crude as it must sound)
>>would be a quick-and-dirty solution, but since the packets don't enter
>>that chain.. Well, it's a non-starter :( 
>>
>>Why are the packets dropped?   The requests are sent out over the same
>>interface on which they are received (Which is a noted caveat for
>>netfilter).  
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>    
>>
>
>
>  
>
I only get to do something like that with CONNMARK patch. With this 
patch the packet returns through the right route.

-Carlo

Multiple routes by uid-owner

[CJ East]

(My apologies if this is a repeat message-- netfilter.org appeared to be 
having some difficulties at the time of my original posting yesterday, 
and the new post has not appeared-- I'm assuming it's been lost) 

Hi, 

I'm currently trying to test several independent internet links. 

To do this, I instantiate two or more interfaces, which I aim to allow
to route packets as though two separate machines were each independently
connected to the internet, and independently downloading some file using
http. 

- I run wget http://www.google.com with uid=500
- I run wget http://www.google.com with uid=501 

- I set up using iptables; 
chain OUTPUT
 MARK all -- anywhere    anywhere  OWNER UID match 500 MARK set 0x1
 MARK all -- anywhere    anywhere  OWNER UID match 501 MARK set 0x2


- I set up using ip; 

ip rule add fwmark 1 table link1
ip rule add fwmark 2 table link2 
ip route add default dev ppp0 table link1
ip route add default dev ppp1 table link2

- This all works more-or-less correctly.  
Now, running wget and tcpdump reveals a DNS lookup going out on the
correct interface, depending of course which userid is running. 

Notably, the SOURCE address isn't that of the PPP interface, it's of
another (ethernet) interface in the machine.  Now, for profiling the
connection, this is clearly unacceptable (Packets need to come back on
the interface they were sent!)  Now, IIUC, an application can bind to
any given source address-- but this is a bad idea in my case, since it
requires each application be aware of its environment-- fine if my test
is ALWAYS wget (since I have the source), but bad generally. 

So, I've turned to SNAT, which I'm abusing to switch the source IP
address to that of the ppp interface on the way out.  

A la, 

iptables -t nat -A POSTROUTING -o ppp0 -j SNAT --to-source x.x.x.x 

This certainly fixes the issue of errant source address, but now, a
totally different problem..... Packets coming IN off the ppp interface
(now bearing the correct address) don't appear to make it to the
application! :( 

I had no idea what was going on, but suffice to say started messing
around with the PREROUTING table enough to notice that these returning
packets don't seem to traverse that hook either; they must be dropped
somewhere in the kernel, however I'm not sure where or why.  I had been
thinking that a corresponding DNAT rule (as crude as it must sound)
would be a quick-and-dirty solution, but since the packets don't enter
that chain.. Well, it's a non-starter :( 

Why are the packets dropped?   The requests are sent out over the same
interface on which they are received (Which is a noted caveat for
netfilter).  

Multiple routes by uid-owner

[CJ East]

Hi, 

I'm currently trying to test several independent internet links. 

To do this, I instantiate two or more interfaces, which I aim to allow
to route packets as though two separate machines were each independently
connected to the internet, and independently downloading some file using
http. 

- I run wget http://www.google.com with uid=500
- I run wget http://www.google.com with uid=501 

- I set up using iptables; 
chain OUTPUT
 MARK all -- anywhere    anywhere  OWNER UID match 500 MARK set 0x1
 MARK all -- anywhere    anywhere  OWNER UID match 501 MARK set 0x2


- I set up using ip; 

ip rule add fwmark 1 table link1
ip rule add fwmark 2 table link2 
ip route add default dev ppp0 table link1
ip route add default dev ppp1 table link2

- This all works more-or-less correctly.  
Now, running wget and tcpdump reveals a DNS lookup going out on the
correct interface, depending of course which userid is running. 

Notably, the SOURCE address isn't that of the PPP interface, it's of
another (ethernet) interface in the machine.  Now, for profiling the
connection, this is clearly unacceptable (Packets need to come back on
the interface they were sent!)  Now, IIUC, an application can bind to
any given source address-- but this is a bad idea in my case, since it
requires each application be aware of its environment-- fine if my test
is ALWAYS wget (since I have the source), but bad generally. 

So, I've turned to SNAT, which I'm abusing to switch the source IP
address to that of the ppp interface on the way out.  

A la, 

iptables -t nat -A POSTROUTING -o ppp0 -j SNAT --to-source x.x.x.x 

This certainly fixes the issue of errant source address, but now, a
totally different problem..... Packets coming IN off the ppp interface
(now bearing the correct address) don't appear to make it to the
application! :( 

I had no idea what was going on, but suffice to say started messing
around with the PREROUTING table enough to notice that these returning
packets don't seem to traverse that hook either; they must be dropped
somewhere in the kernel, however I'm not sure where or why.  I had been
thinking that a corresponding DNAT rule (as crude as it must sound)
would be a quick-and-dirty solution, but since the packets don't enter
that chain.. Well, it's a non-starter :( 

Why are the packets dropped?   The requests are sent out over the same
interface on which they are received (Which is a noted caveat for
netfilter).