Unmatchable packet?

Unmatchable packet?

[Jesse Gordon]

My box is running a TCP service. When another box tries to my box, my box 
responds with a reply packet.(Just like it should.)
 How do I match that (and all subsequent) reply packets so I can SNAT on 
them?

I even tried:

iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to 222.222.222.222

and sure enough, everything going out eth1 was 'from' 222.222.222.222 except 
the reply packets to incoming connections.

Also tried -t nat OUTPUT, -t mangle OUTPUT, etc.. Nothing seemed to work.

Should I expect such a feat to be possible?

Thanks!

-Jesse 

Re: Unmatchable packet?

[Jesse Gordon]

----- Original Message ----- 
From: "Jesse Gordon" <jesseg@nikola.com>
> My box is running a TCP service. When another box tries to my box, my box

I meant 'When another box tries to _connect to_ my box...'

-Jesse

> responds with a reply packet.(Just like it should.)
> How do I match that (and all subsequent) reply packets so I can SNAT on 
> them?
>
> I even tried:
>
> iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to 222.222.222.222
>
> and sure enough, everything going out eth1 was 'from' 222.222.222.222 
> except the reply packets to incoming connections.
>
> Also tried -t nat OUTPUT, -t mangle OUTPUT, etc.. Nothing seemed to work.
>
> Should I expect such a feat to be possible?
>
> Thanks!
>
> -Jesse
>
>
> 

Re: Unmatchable packet?

[Nikolai Georgiev]

Jesse Gordon wrote:

> ----- Original Message ----- From: "Jesse Gordon" <jesseg@nikola.com>
>
>> My box is running a TCP service. When another box tries to my box, my
>> box
>
>
> I meant 'When another box tries to _connect to_ my box...'
>
> -Jesse
>
>> responds with a reply packet.(Just like it should.)
>> How do I match that (and all subsequent) reply packets so I can SNAT
>> on them?
>>
>> I even tried:
>>
>> iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to 222.222.222.222
>>
>> and sure enough, everything going out eth1 was 'from' 222.222.222.222
>> except the reply packets to incoming connections.
>>
>> Also tried -t nat OUTPUT, -t mangle OUTPUT, etc.. Nothing seemed to
>> work.
>>
>> Should I expect such a feat to be possible?
>>
>> Thanks!
>>
>> -Jesse
>>
>>
>>
>
I think you are looking for DNAT. Yep, you want to make DNAT. Lets
suppose you have 3 machines: A,B,C; A is behind B and you are on C. You
would want to make a DNAT rule on B to A in order to initiate
connections from C to A...

>
>
>

Re: Unmatchable packet?

[Jesse Gordon]

----- Original Message ----- 
From: "Nikolai Georgiev" <voyager123bg@gmail.com>
To: "Jesse Gordon" <jesseg@nikola.com>
Cc: <netfilter@lists.netfilter.org>
Sent: Tuesday, November 22, 2005 4:46 PM
Subject: Re: Unmatchable packet?


> Jesse Gordon wrote:
>
>> ----- Original Message ----- From: "Jesse Gordon" <jesseg@nikola.com>
>>
>>> My box is running a TCP service. When another box tries to my box, my
>>> box
<snip>
>>>
>>> Should I expect such a feat to be possible?
>>>
>>> Thanks!
>>>
>>> -Jesse
>>>
>>>
>>>
>>
> I think you are looking for DNAT. Yep, you want to make DNAT. Lets
> suppose you have 3 machines: A,B,C; A is behind B and you are on C. You
> would want to make a DNAT rule on B to A in order to initiate
> connections from C to A...

Thanks for your response!

You are correct as to how I would go about forwarding ports to publish an 
internal server -- but forwarding ports isn't my goal.

Incidently I didn't explain well I guess.

Note that what I'm trying to describe is not a normal thing to do; It's not 
something that will make sense. Once you understand what I'm trying to say, 
you'll want to ask me "But why on earth would you even want to do that?" (My 
goal does have a use in the real world, but the real world is a much more 
complicated scenerio to set up.)

I actually want to rewrite the source IP of TCP packets that exit a given 
ethernet card -- even (especially) if they are generated as responses to 
incoming connections to the box.

 Lets say I have 2 machines: S, and C;
S is the server, and I am on C[lient]. Both machines are sitting on a simple 
isolated flat LAN.

Normally, when C connects to S, S replies with it's own source address. This 
is normal operation, and is what I want to alter.
I wish for the replies from S to be to reach C with an arbitrarly assigned 
source address.
(And I want the source address rewrite to be performed inside S)

I hope I was more concise this time.

Thanks again!

-Jesse

>
>>
>>
>>
>
> 

Re: Unmatchable packet?

[Philip Craig]

On 11/23/2005 11:46 AM, Jesse Gordon wrote:
> I actually want to rewrite the source IP of TCP packets that exit a given 
> ethernet card -- even (especially) if they are generated as responses to 
> incoming connections to the box.
> 
>  Lets say I have 2 machines: S, and C;
> S is the server, and I am on C[lient]. Both machines are sitting on a simple 
> isolated flat LAN.
> 
> Normally, when C connects to S, S replies with it's own source address. This 
> is normal operation, and is what I want to alter.
> I wish for the replies from S to be to reach C with an arbitrarly assigned 
> source address.
> (And I want the source address rewrite to be performed inside S)

You can't do this with iptables.  NAT rules only match the first packet
of a connection, and the NAT mapping that is determined for that first
packet is applied to all subsequent packets in that connection.

Futhermore, it doesn't make sense to do this.  The client will receive
packets from your arbitarily assigned source address, but will not know
what to do with them since it never sent any packets to that address,
and so it will just drop them.

Re: Unmatchable packet?

[Jesse Gordon]

-----Original Message-----
From: Philip Craig <philipc@snapgear.com>
Subject: Re: Unmatchable packet?

> On 11/23/2005 11:46 AM, Jesse Gordon wrote:
> > I actually want to rewrite the source IP of TCP packets that exit a given 
> > ethernet card -- even (especially) if they are generated as responses 
> > to incoming connections to the box.
[Snip] 

> You can't do this with iptables.  NAT rules only match the first packet
> of a connection, and the NAT mapping that is determined for that first
> packet is applied to all subsequent packets in that connection.
> 
> Futhermore, it doesn't make sense to do this.  The client will receive
> packets from your arbitarily assigned source address, but will not know
> what to do with them since it never sent any packets to that address,
> and so it will just drop them.

Ahh, thanks! Can't be done. That explains my lack of success!

I agree -- to do as my little example showed would be useless -- but my
real goal is to route the reply traffic via a different route than the
request traffic -- I already got it to send the replies out a different
network interface then the requests came in, but I haven't yet figured out
how to rewrite the source address of the replies.

I only simplified the example so that no other unneeded data would
obfusticate what I was saying.

By using a second box with iptables as an inbetween gateway, or with proxy
arp filtering or ethernet bridging, I could probably do exactly what I
want. Perhaps I'll see what ebtables can do for me.

I don't quite understand why iptables wouldn't be able to match just any
packet going into or out of any given network card, regardless of whether
it was related to any other packet or not.

I may be a little confused. It seems to me that my experiments showed that
the act of permitting a certain packet criteria to exit a specified
ethernet port does not inherently permit the responses for that connection
back in. It seems to me that I had to either tell it to allow related in,
or specifically allow the replies back. I'll check into it more.

Thanks very much!

-Jesse Gordon

Re: Unmatchable packet?

[Philip Craig]

On 11/23/2005 05:03 PM, Jesse Gordon wrote:
> I agree -- to do as my little example showed would be useless -- but my
> real goal is to route the reply traffic via a different route than the
> request traffic -- I already got it to send the replies out a different
> network interface then the requests came in, but I haven't yet figured out
> how to rewrite the source address of the replies.

Why do you need to rewrite the address?
Just routing the packet should be enough, unless there is an
intermediate firewall that is dropping the packets based on the
source address.

> I don't quite understand why iptables wouldn't be able to match just any
> packet going into or out of any given network card, regardless of whether
> it was related to any other packet or not.
> 
> I may be a little confused. It seems to me that my experiments showed that
> the act of permitting a certain packet criteria to exit a specified
> ethernet port does not inherently permit the responses for that connection
> back in. It seems to me that I had to either tell it to allow related in,
> or specifically allow the replies back. I'll check into it more.

I think you are confusing the nat and filter tables.

The nat table only sees the first packet of a connection, because it
is designed to set up the nat mapping based on the first packet only.

The filter table does see every packet, which is why you need the rule
to allow established/related packets.

The mangle table also sees every packet.  It would be possible to write
a custom target for use in the mangle table that changes the source
address as you desire.  However, noone has written such a target as
far as I know.

Re: Unmatchable packet?

[Jesse Gordon]

I should probably make note here that while I have a nearly working 
understanding of the ip packets, source/dest ports/ips, and the like,
I do not have a firm grasp on how iptables deals with them -- other then 
that packets can sometimes be matched by addresses, ports, and other 
criteria.

I also understand the concept of a stateless firewall -- blocking or 
readdressing packets in a mindless mechanical way with no memory of history.

But it seems that much of iptables is far more stateful then I realize, and 
exactly how the internal workings do their thing seems to confuse me in a 
case like my attempts to do
asymmetrical nat routing.

Note that for normal stuff like forwarding ports, blocking ports, and so on, 
iptables does make sense to me and generally seems to do what I'd expect.

The reason I explain all of this is so that you have a better idea of what 
existing understanding I have, and where I'm clueless, in case you
are so generous as to mention a couple of things to me.

I've been reading in Oskar Andreasson's Iptables Tutorial, but it has a lot 
of information on the general topic of networking, which makes it slow to 
find what I need to know.

Anyone know of a short concise website that tells me what I can and can't do 
in each table, what they are for, and what order they are tested in?
That might help me immensely.

I ran across a new word (new only to me) 'Fast-nat' -- seems some kernels --  
at least 2.2 kernels -- had some fast simple dumb stateless natting 
capabilities in them.
I wonder if that's what I should be looking into.

My comments about my actual problem are below.


----- Original Message ----- 
From: "Philip Craig" <philipc@snapgear.com>
To: "Jesse Gordon" <jesseg@nikola.com>
Cc: "Nikolai Georgiev" <voyager123bg@gmail.com>; 
<netfilter@lists.netfilter.org>
Sent: Tuesday, November 22, 2005 11:19 PM
Subject: Re: Unmatchable packet?


> On 11/23/2005 05:03 PM, Jesse Gordon wrote:
>> I agree -- to do as my little example showed would be useless -- but my
>> real goal is to route the reply traffic via a different route than the
>> request traffic -- I already got it to send the replies out a different
>> network interface then the requests came in, but I haven't yet figured 
>> out
>> how to rewrite the source address of the replies.
>
> Why do you need to rewrite the address?
> Just routing the packet should be enough, unless there is an
> intermediate firewall that is dropping the packets based on the
> source address.

I need to rewrite the address so the calling party gets replies with the 
correct source address.
I've very carefully created a .PNG diagram on this webpage including IPs and 
text descriptions here:
http://jesseg.nikola.com:8080/asym-nat-route/
This will explain Exactly what I'm trying to do, and why I need to snat on 
the connection replies.

As shown in the diagram, I did set up an experiment that did what I wanted, 
except I had to use an extra nat iptables box.
That's the first shown diagram on the webpage mentioned above.
It seems iptables has no problem matching and SNATting reply packets as long 
as they aren't the reply packets generated
by a local server.


>
> I think you are confusing the nat and filter tables.
>

I don't know the difference between nat and filter, except that nat is the 
only one that can do nat, I think.

>
> The nat table only sees the first packet of a connection, because it
> is designed to set up the nat mapping based on the first packet only.
>

I've been reading a little in the iptables tutorial by Oskar Andreasson --  
and he says the same thing as you.

But it seems to me that nat can match on all packets that are forwarded, but 
I may be confused on this.

I did this experiment (unrelated to the diagrams above):
Workstation: 10.0.0.6 with a default gw of 10.0.0.5
iptables firewall box: WAN=64.146.180.164, LAN=10.0.0.5, default gw 
64.146.180.225
Then I did:

#Prevent packets from being sent out with a src address of 10.0.0.6:
iptables -t nat -A POSTROUTING -o eth1 -s 10.0.0.6 -j SNAT --to-source 
64.146.180.164
#Forward incoming packets to 10.0.0.6..
iptables -t nat -A PREROUTING -i eth1 -d 64.146.180.164 -j DNAT --to 
10.0.0.6

And this is without any masquerading rules, and with rules to allow 
forwarding to and from 10.0.0.6.

(I realize this could have been done with a masq rule instead of the first 
postrouting -- but I wanted to see if the two nat rules worked, and I also 
need to specify which source IP was used.)

This created a two way path -- in other words, the Workstation could connect 
out to the outside world, and the outside
world could connect in to the workstation.

I don't think it would work if either of the nat rules were absent -- which 
must mean that they both are working..
Maybe both rules always thought that they were always just getting the first 
packet?

In other words, when a connection is initiated by the Workstation, not only 
is the first nat rule natting the first request packet,
the second nat rule is also matching and natting the reply packet. Same 
thing with the incoming connection.

But shouldn't the reply packet be ignored by all nat rules, since nat only 
sees first packet of connection?

Anyhow, I'm trying hard to learn this cool world of iptables, and am 
struggling in my efforst to have it cohere.

I really do appreciate all of your effort in trying to help me!

>
> The filter table does see every packet, which is why you need the rule
> to allow established/related packets.

But I can't nat in any table other then nat, right?

>
> The mangle table also sees every packet.  It would be possible to write
> a custom target for use in the mangle table that changes the source
> address as you desire.  However, noone has written such a target as
> far as I know.
>

'Custom target' = a module or some addition to the source code, right?

Also, is my current understanding that "There are some packets which simply 
cannot be source natted," correct?

It may be that if I knew how to use the 'ip' program, I could do everything 
I need with 'ip route' and so on. I'm certainly open to suggestions.

Thanks very much,

Jesse 

Re: Unmatchable packet?

[Robert Nichols]

Jesse Gordon wrote:
> Anyone know of a short concise website that tells me what I can and 
> can't do in each table, what they are for, and what order they are 
> tested in?
> That might help me immensely.

That is precisely the information that is in Chapter 6, "Traversing
of Tables and Chains", in the tutorial.  It's just seven pages.

> But shouldn't the reply packet be ignored by all nat rules, since nat 
> only sees first packet of connection?

The nat _rule_ processing occurs only for the first packet, but
whatever translation was determined for that first packet then
gets applied to all subsequent packets of the connection
symmetrically (i.e., in both directions).

-- 
Bob Nichols         Yes, "NOSPAM" is really part of my email address.

Re: Unmatchable packet?

[Philip Craig]

On 11/24/2005 09:48 PM, Jesse Gordon wrote:
> I ran across a new word (new only to me) 'Fast-nat' -- seems some kernels --  
> at least 2.2 kernels -- had some fast simple dumb stateless natting 
> capabilities in them.
> I wonder if that's what I should be looking into.

The custom mangle target that I referred to would have the same
function as fast-nat (although it wouldn't be as fast ;-)
2.4 also has fast-nat, but I couldn't see it in 2.6.

> I need to rewrite the address so the calling party gets replies with the 
> correct source address.
> I've very carefully created a .PNG diagram on this webpage including IPs and 
> text descriptions here:
> http://jesseg.nikola.com:8080/asym-nat-route/
> This will explain Exactly what I'm trying to do, and why I need to snat on 
> the connection replies.

Okay I can see what you are doing here, and it isn't going to
work with standard iptables NAT.  Assymetrical routing and NAT
are incompatible.

Even your "working" case is not ideal, each direction is seeing
only half the packets and so they can't keep state fully.  Anything
that requires a NAT helper will fail.  eg FTP data connections

> It seems iptables has no problem matching and SNATting reply packets as long 
> as they aren't the reply packets generated
> by a local server.

No.  It has no problem matching and SNATing replies as long
as they are the first packet of the connection that it sees.

> In other words, when a connection is initiated by the Workstation, not only 
> is the first nat rule natting the first request packet,
> the second nat rule is also matching and natting the reply packet. Same 
> thing with the incoming connection.
> 
> But shouldn't the reply packet be ignored by all nat rules, since nat only 
> sees first packet of connection?

See Robert's explanation.
Also, try doing 'iptables -t nat -L -nv' and look at the packet
counts on the rules to see exactly which are matching.

> But I can't nat in any table other then nat, right?

Correct.

>>The mangle table also sees every packet.  It would be possible to write
>>a custom target for use in the mangle table that changes the source
>>address as you desire.  However, noone has written such a target as
>>far as I know.
>>
> 
> 
> 'Custom target' = a module or some addition to the source code, right?

Yes.

> Also, is my current understanding that "There are some packets which simply 
> cannot be source natted," correct?

Incorrect.  The source natting is determined by the first packet
in the connection.   You cannot *change* this source natting for
subsequent packets.

> It may be that if I knew how to use the 'ip' program, I could do everything 
> I need with 'ip route' and so on. I'm certainly open to suggestions.

Yes.  You can use CONNMARK to mark connections that are initially
received on the internal interface, and then use 'ip rule' and 'ip route'
to route those packets back out the internal interface to the
Box A, which will use its existing NAT mapping to correctly source
NAT them automatically (ie no further NAT rules required).

Re: Unmatchable packet?

[Jesse Gordon]

Philip, Robert, and whoever else:

Thanks! You guys have done an outstanding job of explaining this to me.
It's all starting to make a little bit of sense!

----- Original Message ----- 
From: "Philip Craig" <philipc@snapgear.com>
Subject: Re: Unmatchable packet?
> Okay I can see what you are doing here, and it isn't going to
> work with standard iptables NAT.  Assymetrical routing and NAT
> are incompatible.
>
> Even your "working" case is not ideal, each direction is seeing
> only half the packets and so they can't keep state fully.  Anything
> that requires a NAT helper will fail.  eg FTP data connections

FTP might not fail since the one public routable IP is being mapped directly 
to exactly one non routable private IP,
so the asymetry should be invisable to either end. In any case, I agree --  
[ab]using iptables like this is not ideal.

>> It seems iptables has no problem matching and SNATting reply packets as 
>> long
>> as they aren't the reply packets generated
>> by a local server.
>
> No.  It has no problem matching and SNATing replies as long
> as they are the first packet of the connection that it sees.

I'd been assuming that the type of packet mattered -- but no, it's just 
whether it's the first seen by iptables.

> Yes.  You can use CONNMARK to mark connections that are initially
> received on the internal interface, and then use 'ip rule' and 'ip route'
> to route those packets back out the internal interface to the
> Box A, which will use its existing NAT mapping to correctly source
> NAT them automatically (ie no further NAT rules required).
>

This sounds like the way to go -- I'll learn what CONNMARK means, and how to 
use ip rule and route.

Thanks very much!

-Jesse