DNAT, Is it possible to find the original destination?

DNAT, Is it possible to find the original destination?

[lumberjack]

iptables 1.2.9 on SuSE 9.1

I am using iptables redirection to send things inbound to port 80 to 
localhost:8080:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to 8080

Is there any way that my application can look in the table and see the real 
destination?  I've seen several things in patch-o-matic that do things with 
conntrack but there doesn't seem to be any command, /proc or /dev entry 
available to query "i have a connection from host foo, iptables, who was foo 
really wanting to speak too?".

Thanks,
Jason

Re: DNAT, Is it possible to find the original destination?

[Jason Opperisano]

On Mon, Nov 01, 2004 at 09:30:26AM -0600, lumberjack@lumberjackvillage.com wrote:
> iptables 1.2.9 on SuSE 9.1
> 
> I am using iptables redirection to send things inbound to port 80 to 
> localhost:8080:
> 
> iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to 8080
> 
> Is there any way that my application can look in the table and see the real 
> destination?  I've seen several things in patch-o-matic that do things with 
> conntrack but there doesn't seem to be any command, /proc or /dev entry 
> available to query "i have a connection from host foo, iptables, who was foo 
> really wanting to speak too?".

well, in the case of you example port (80), if you're talking about an
HTTP request, the original destination of the request is preserved in the
"Host: " header.  this is how transparent proxying works.

in the general case, i don't suppose there's anything stopping you from
performing a lookup against /proc/net/ip_conntrack within your app to
find the original dst ip (although it's been pointed out here recently
that lookups against /proc/net/ip_conntrack are a bad idea--check the
archives).

-j

--
"If something is to hard to do, then it's not worth doing."
        --The Simpsons

Re: DNAT, Is it possible to find the original destination?

[Lumberjack]

>> Is there any way that my application can look in the table and see the 
>> real
>> destination?  I've seen several things in patch-o-matic that do things 
>> with
>> conntrack but there doesn't seem to be any command, /proc or /dev entry
>> available to query "i have a connection from host foo, iptables, who was 
>> foo
>> really wanting to speak too?".
>
> well, in the case of you example port (80), if you're talking about an
> HTTP request, the original destination of the request is preserved in the
> "Host: " header.  this is how transparent proxying works.
>
> in the general case, i don't suppose there's anything stopping you from
> performing a lookup against /proc/net/ip_conntrack within your app to
> find the original dst ip (although it's been pointed out here recently
> that lookups against /proc/net/ip_conntrack are a bad idea--check the
> archives).
>
> -j
>

Couple follow ups.  I searched back the last two or three months and didn't 
find any "no nos" on using /proc/net/ip_conntrack.  All I can figure is that 
it could be a hit to read through if very large.  Not sure yet how /proc fs 
might lock things either (if that might be an issue).  So any reason for 
using this to be a "bad thing" please provide some sort of hint if possible.

Another.  If I do something to read in the contents of 
/proc/net/ip_conntrack and then do something to send some output to stdin of 
iptables-restore/iptables does my app need to be GPL based?  Boarders here 
seem rather grey.  I am not modifying any GPL code nor extending it so it 
doesn't seem to me be something that "modifies" and thus requires to be 
released under the GPL.

Thanks,
Jason

Re: DNAT, Is it possible to find the original destination?

[Jason Opperisano]

On Tue, Nov 02, 2004 at 01:11:19AM -0500, Lumberjack wrote:
> Couple follow ups.  I searched back the last two or three months and didn't 
> find any "no nos" on using /proc/net/ip_conntrack.  All I can figure is 
> that it could be a hit to read through if very large.  Not sure yet how 
> /proc fs might lock things either (if that might be an issue).  So any 
> reason for using this to be a "bad thing" please provide some sort of hint 
> if possible.

the thread that it ended up coming out in that i was thinking of:

  http://marc.theaimsgroup.com/?l=netfilter&m=109649105915501&w=2

and yes--it has to do with read locking.

> Another.  If I do something to read in the contents of 
> /proc/net/ip_conntrack and then do something to send some output to stdin 
> of iptables-restore/iptables does my app need to be GPL based?  Boarders 
> here seem rather grey.  I am not modifying any GPL code nor extending it so 
> it doesn't seem to me be something that "modifies" and thus requires to be 
> released under the GPL.

can't help ya there...

-j

--
"Here we have an ordinary square.
 Whoa! Slow down egghead!"
        --The Simpsons

Re: DNAT, Is it possible to find the original destination?

[Jason Lunz]

lumberjack@lumberjackvillage.com said:
> iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to 8080
>
> Is there any way that my application can look in the table and see the real 
> destination?  I've seen several things in patch-o-matic that do things with 

iirc, doesn't the SO_ORIGDST sockopt (or something like that) tell you
this?

Jason

RE: DNAT, Is it possible to find the original destination?

[Daniel Chemko]

-m conntrack is the key here:

conntrack match v1.2.9 options:
 [!] --ctstate
[INVALID|ESTABLISHED|NEW|RELATED|UNTRACKED|SNAT|DNAT][,...]
                                State(s) to match
 [!] --ctproto  proto           Protocol to match; by number or name,
eg. `tcp'
     --ctorigsrc  [!] address[/mask]
                                Original source specification
     --ctorigdst  [!] address[/mask]
                                Original destination specification
     --ctreplsrc  [!] address[/mask]
                                Reply source specification
     --ctrepldst  [!] address[/mask]
                                Reply destination specification
 [!] --ctstatus [NONE|EXPECTED|SEEN_REPLY|ASSURED|CONFIRMED][,...]
                                Status(es) to match
 [!] --ctexpire time[:time]     Match remaining lifetime in seconds
against
                                value or range of values (inclusive)