How to Lookup NAT Mapping?

Hello,

We have Linux-based firewall systems here running 2.4 and 2.6 kernels.
Several iptables rules are used to configure NAT from external to
internal addresses. I'm working on some software for them, and need to
be able to determine on the fly whether a given outbound destination
IP address will be rewritten by the NAT subsystem, and if so, what
source/destination addresses will be assigned to the connection.

Is there a good way to do that? I've tried in vain to coerce Netlink
into giving me this information, but all I can ever seem to get when
looking up routes with the external address as destination is a reply
telling me the external address. I see that there is an RTN_NAT type
defined, but it doesn't seem to have any effect on the query (the
result is the same as specifying RTN_UNICAST).

Does anyone have suggestions? Pointers?

Thanks!

TN

I am not sure if this is what you;re after but

iptables -L -t nat

will give you the current NAT-ing tables

Roberto



(E-Mail Removed) (TN) wrote in message news:<(E-Mail Removed). com>...
> Hello,
>
> We have Linux-based firewall systems here running 2.4 and 2.6 kernels.
> Several iptables rules are used to configure NAT from external to
> internal addresses. I'm working on some software for them, and need to
> be able to determine on the fly whether a given outbound destination
> IP address will be rewritten by the NAT subsystem, and if so, what
> source/destination addresses will be assigned to the connection.
>
> Is there a good way to do that? I've tried in vain to coerce Netlink
> into giving me this information, but all I can ever seem to get when
> looking up routes with the external address as destination is a reply
> telling me the external address. I see that there is an RTN_NAT type
> defined, but it doesn't seem to have any effect on the query (the
> result is the same as specifying RTN_UNICAST).
>
> Does anyone have suggestions? Pointers?
>
> Thanks!
>
> TN

TN wrote:

> Hello,
Hi!

> We have Linux-based firewall systems here running 2.4 and 2.6 kernels.
> Several iptables rules are used to configure NAT from external to
> internal addresses. I'm working on some software for them, and need to
> be able to determine on the fly whether a given outbound destination
> IP address will be rewritten by the NAT subsystem, and if so, what
> source/destination addresses will be assigned to the connection.
Well, NAT generally doesn't rewrite destination addresses, but source
addresses, so that the reply packets reach the NAT router.

Anyway, short of reimplementing the routing subsystem of the Linux
kernel, I'd recommend to configure your program with address ranges for
internal and external IP addresses and do some comparisons to check
which range (internal/internal, internal/external, etc.) your addresses
fall into.

If you need information about the currently masqueraded connections, you
can read /proc/net/ip_conntrack.

Beat

TN wrote:
> We have Linux-based firewall systems here running 2.4 and 2.6 kernels.
> Several iptables rules are used to configure NAT from external to
> internal addresses. I'm working on some software for them, and need to
> be able to determine on the fly whether a given outbound destination
> IP address will be rewritten by the NAT subsystem, and if so, what
> source/destination addresses will be assigned to the connection.

This one is not quite clear to me: If You want to see what connections
are currently masqueraded, try 'cat /proc/net/ip_conntrack'.

If You want to know how connections are to be masqueraded, well, this
is what You specify Yourself via iptables.

If, on the other hand, You want to see "what will be assigned", You'll
need to go a bit more in-depth (assuming that, semantically, "will" is
used as a future term in this context). - Anyways, normally, the MASQ
target of iptables will not alter neither source nor destination port
of the packet, but (outgoing) only SNAT the packet in question and,
correspondingly, DNAT the incoming reply, both based on the connection
tracking that all MASQing is based upon.


> Is there a good way to do that? I've tried in vain to coerce Netlink
> into giving me this information, but all I can ever seem to get when
> looking up routes with the external address as destination is a reply
> telling me the external address. I see that there is an RTN_NAT type
> defined, but it doesn't seem to have any effect on the query (the
> result is the same as specifying RTN_UNICAST).
>
> Does anyone have suggestions? Pointers?

Again, please clarify what exactly You're after.


Cheers, Jack.

--
----------------------------------------------------------------------
My personal reading of the string "MicroSoft" expands to "NanoWeak"...

(E-Mail Removed) (roberto) wrote in message news:<(E-Mail Removed). com>...
> I am not sure if this is what you;re after but
>
> iptables -L -t nat
>
> will give you the current NAT-ing tables

That's true, of course, but the output can become complex if you start
adding match qualifiers to DNAT/SNAT rules. I was hoping for a binary
interface that had the kernel go through the binary representation of
the rules and simply tell me what the mapping would be. Otherwise I'd
have to reimplement the iptables command interpreter and the
underlying rule-matching logic in my code, which seems like a waste of
time and effort when the kernel already knows how to do it.

I thought Netlink would be the perfect solution, but I haven't been
able to make it do the job...

Anyway, thanks!

TN

Hello!

eat Bolli <(E-Mail Removed)> wrote in message news:<4124f1a1$0$2812$(E-Mail Removed)>...
> Well, NAT generally doesn't rewrite destination addresses, but source
> addresses, so that the reply packets reach the NAT router.

I guess it's a matter of how you look at it. Obviously the rewrite has
to be done in both directions, but since the connections we're working
with are mostly inbound, we use mostly DNAT rules, mapping external
global addresses to internal private ones. We just let conntrack
handle the reverse mapping.

> Anyway, short of reimplementing the routing subsystem of the Linux
> kernel, I'd recommend to configure your program with address ranges for
> internal and external IP addresses and do some comparisons to check
> which range (internal/internal, internal/external, etc.) your addresses
> fall into.

That's not really an option in our case. Or I should say, this is
similar to what we're doing now, but we have thousands of firewalls
to manage and manual configuration has proven to be a source of
unacceptable errors. I need a solution that I can just drop into a box
and have it dynamically determine whether a given flow is going to be
NAT'ed or not, and if so, what the changes (source and destination)
will be. I'm don't think this is 100% achievable without patching the
kernel, but I thought there might be a way to handle 95% of the cases
(simple networks) automatically, then use special case configuration
where needed.

The thing is... the kernel can obviously do this (compute the
mappings). All I need is a way to access that expertise from
userspace. Netlink seems like the ideal thing, but it doesn't seem to
provide NAT data.

> If you need information about the currently masqueraded connections, you
> can read /proc/net/ip_conntrack.

Well, there are a couple of problems. First, I'm not sure
/proc/net/ip_conntrack has any indication of whether a connection was
rewritten via NAT rules. I have a vague recollection that it doesn't.
And then more importantly, what I need to do is determine what the
mapping will be BEFORE the connection is actually made, so conntrack
won't be of much help there.

Thanks for your help! It's a puzzle.

TN

TN wrote:
> The thing is... the kernel can obviously do this (compute the
> mappings). All I need is a way to access that expertise from
> userspace. Netlink seems like the ideal thing, but it doesn't seem to
> provide NAT data.

Ah, I think I'm getting the point now.

Firstly, what exactly are You trying to achieve with all this...?
The decision whether and how to NAT packets should, under "normal"
circumstances, be made and clear before any one packet arrives.

Anyways, in Your case, I'd simply alter the natting code in the
kernel, in such a way that it spits its results into userspace as
sonn as it made its decision and then, if that is what You want,
only continue after it got its "GO" from anywhere that You specify.

Again, to me this sounds like a conceptionally wrong way to tackle
things. I'd try to find an entirely different approach.


Cheers, Jack.

--
----------------------------------------------------------------------
My personal reading of the string "MicroSoft" expands to "NanoWeak"...

jack <(E-Mail Removed)> wrote in message news:<cg355e$97q$07$(E-Mail Removed)>...
> Again, please clarify what exactly You're after.

Sorry for the confusion. I'm looking for an automated (programmatic)
way to determine, before a connect() is made, how the <src,dst> pair
of a locally geneated packet (CONFIG_IP_NF_NAT_LOCAL enabled) will be
rewritten by the NAT subsystem -- how the SYN packet will appear to be
addressed when it exits the router interface. This will be used in
software that will be deployed on several thousand systems which I
have not configured.

I realize that in complex routing environments, it may not be possible
to do this reliably, but for the 95% that are simple networks, it
should be possible. I just haven't found the way yet...

Thanks!

TN

TN wrote:
> jack <(E-Mail Removed)> wrote in message news:<cg355e$97q$07$(E-Mail Removed)>...
>
>>Again, please clarify what exactly You're after.
>
>
> Sorry for the confusion. I'm looking for an automated (programmatic)
> way to determine, before a connect() is made, how the <src,dst> pair
> of a locally geneated packet (CONFIG_IP_NF_NAT_LOCAL enabled) will be
> rewritten by the NAT subsystem -- how the SYN packet will appear to be
> addressed when it exits the router interface. This will be used in
> software that will be deployed on several thousand systems which I
> have not configured.
>
> I realize that in complex routing environments, it may not be possible
> to do this reliably, but for the 95% that are simple networks, it
> should be possible. I just haven't found the way yet...

Well, in this context, libcap jumps into my mind... - It does exactly
what You want, and if You need some extra functionallity which this
does not provide, it is sure the best point to start from.

And yet I am not convinced that I really got Your point entirely... -
If this answer does not help You, please be kind and try to explain the
whole thing over from the beginning... - Sorry.


Cheers, Jack.

--
----------------------------------------------------------------------
My personal reading of the string "MicroSoft" expands to "NanoWeak"...

jack wrote:
>> Sorry for the confusion. I'm looking for an automated (programmatic)
>> way to determine, before a connect() is made, how the <src,dst> pair
>> of a locally geneated packet (CONFIG_IP_NF_NAT_LOCAL enabled) will be
>> rewritten by the NAT subsystem -- how the SYN packet will appear to be
>> addressed when it exits the router interface. This will be used in
>> software that will be deployed on several thousand systems which I
>> have not configured.
>>
>> I realize that in complex routing environments, it may not be possible
>> to do this reliably, but for the 95% that are simple networks, it
>> should be possible. I just haven't found the way yet...
>
>
> Well, in this context, libcap jumps into my mind... - It does exactly
> what You want, and if You need some extra functionallity which this
> does not provide, it is sure the best point to start from.
>
> And yet I am not convinced that I really got Your point entirely... -
> If this answer does not help You, please be kind and try to explain the
> whole thing over from the beginning... - Sorry.

I hit the button a bit early... - Sorry for that very brief statement,
which still is what I wanted to say.

But a bit more in-depth, what exactly is it that You're trying to
achieve? - If it is only some sort of logging, the solution will be
miles easier to achieve than, say, to restrict certain connections from
being made. - When You say that You want to know the resulting packet's
details _before_ it leaves Your box, I may assume that the latter,
namely controlling such connections before they are being initiated, is
what You are after.

Depending on what exactly You are trying to do, I'd say that if the
power of control that You can achieve with a properly designed rule-
set for iptables (or other packet filtering mechanisms, but eventually
iptables is versatile and powerful enough), again if this is not suffi-
cient for Your needs, then there must be one major mislead in the entire
strategy, and I'd recommend to re-design the solution from the beginn-
ing.

This is what is confusing me; I think You are doing Your best to de-
scribe the situation. - If I am not missing something really important
here - which may be the case, of course - I bet for sure that You got
Yourself on the wrong track somehow... - BTW, are You telling us every-
thing about this, or did You leave out something important...?


Anyways, I'm sure we'll get You back up the road, Jack.

--
----------------------------------------------------------------------
My personal reading of the string "MicroSoft" expands to "NanoWeak"...