NAT in an already established TCP connection
Hello all!!!
This is my first mail in the list.
Hopefully the question is interesting and you can figure out how to help me.
I use iptables rules to manage the connections from internet to my local network. I know how to filter, do nat, etc...
But this days I'm trying to do NAT in connections that are already established. The problem is (as far as I know) the packets which pass throught the nat table are only the SYN packets (once), thus, the packets that are used to perform a NEW connection.
After that the connection is created, the maintenance and the resolution of the SNAT and DNAT are kept till the connection finish.
What I'm wondering is: how can I change the ports or IPs of an already established connection if my packets just go throught the nat table at the connection time?
**** Maybe doing packets' replication since those ones are redirected to annother machine?
**** NAT TCP Extensions??Patch-O-Matic --> window-tracking??
**** I read this in an interntet site:
--- NEW (and RELATED non-icmp)
This is a very important part relevant for understanding the whole NAT subsystem. Only if the packet has the state NEW (i.e. it would establish a new connection, if we'd accept it), the NAT table is traversed by calling ip_nat_rule.c:ip_nat_rule_find(), which in turn calls ip_tables.c:ipt_do_table() for the actual IP table traversal. The
traversal
ends up in either ACCEPTing the packet as it is, or one of the nat
targets
(SNAT, DNAT and if loaded: REDIRECT, MASQUERADE) Please see chapter FIXME for further description of those targets.
--- ESTABLISHED
This packet belongs to an already established connection. We don't need to traverse the NAT table again, as the necessary information (struct ip_nat_info) was already gained Hello everybody,
Thank you very much in advance and if my questions are not clear don't doubt to send me a message.
Diego.
Quoted 14 lines · Diego Casado Mansilla
Hello all!!!
This is my first mail in the list.
Hopefully the question is interesting and you can figure out how to help me.
I use iptables rules to manage the connections from internet to my local network. I know how to filter, do nat, etc...
But this days I'm trying to do NAT in connections that are already established. The problem is (as far as I know) the packets which pass throught the nat table are only the SYN packets (once), thus, the packets that are used to perform a NEW connection.
Quoted 6 lines
After that the connection is created, the maintenance and the resolution of the SNAT and DNAT are kept till the connection finish. What I'm wondering is: how can I change the ports or IPs of an already established connection if my packets just go throught the nat table at the connection time?
What you want is to redirect an existing connection to a new destination. If you use TCP protocol, the only way to do that is to record the current connection and, in parralel, create a second connection to you new destination and replay the payload on the packet in the new one.
If you use UDP, this doesn't apply since there's no connection tracking in the UDP protocol. Netfilter, however, does some connection tracking on UDP packets, so make some test to see if it's doable.
I had to solve the same problem in a honeypot project to redirect active connections from low interaction honeypots to high interactions honeypots. The solution I choosed was to queue the connections in userland using netfilter_queue, process them and replay those I've selected to the new destination in parrallel, and then drop the packet from the initial connection.
It's tricky to do, and there's many issue to solve, but AFAIK this is the most reliable solution.
Quoted 2 lines
**** Maybe doing packets' replication since those ones are redirected to annother machine?
Note : window-tracking is for the tracking of the window size in the tcp header, it has nothing to do with this.
Quoted 7 lines
**** NAT TCP Extensions??Patch-O-Matic --> window-tracking??
**** I read this in an interntet site:
--- NEW (and RELATED non-icmp)
This is a very important part relevant for understanding the whole
NAT
Quoted 11 lines
subsystem. Only if the packet has the state NEW (i.e. it would establish
a new connection, if we'd accept it), the NAT table is traversed by calling ip_nat_rule.c:ip_nat_rule_find(), which in turn calls ip_tables.c:ipt_do_table() for the actual IP table traversal. The
traversal
ends up in either ACCEPTing the packet as it is, or one of the nat
targets
(SNAT, DNAT and if loaded: REDIRECT, MASQUERADE) Please see chapter FIXME for further description of those targets.
Quoted 2 lines
--- ESTABLISHED
This packet belongs to an already established connection. We don't
need
Quoted 7 lines
to traverse the NAT table again, as the necessary information (struct
ip_nat_info) was already gained Hello everybody,Thank you very much in advance and if my questions are not clear don't doubt to send me a message.
Quoted 7 lines
Diego.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Regards,
Julien
Signature · 1 line
www.linuxwall.info
Quoted 6 lines · Julien Vehent
Quoted 4 lines · Diego Casado Mansilla
But this days I'm trying to do NAT in connections that are already established. The problem is (as far as I know) the packets which pass throught the nat table are only the SYN packets (once), thus, the packets that are used to perform a NEW connection.
This is so wrong. Any connection that *Netfilter* (not specifically the networking stack) does not yet know about is NEW. That might even be in the middle of a TCP stream -- you can do it: conntrack -F will clear all connections and thus they will begin with NEW. Not that this is something you randomly do on a router which only allows ESTABLISHED or NEW-combined-with-SYN -matched packets.
Quoted 5 lines
Quoted 5 lines
After that the connection is created, the maintenance and the resolution of the SNAT and DNAT are kept till the connection finish. What I'm wondering is: how can I change the ports or IPs of an already established connection if my packets just go throught the nat table at the connection time?
Well they don't go through, hence this is moot. The TCP stack of the final destination will also be confused. Different port -- different connection. Basic rules of networking.
Quoted 3 lines
If you use UDP, this doesn't apply since there's no connection tracking in the UDP protocol. Netfilter, however, does some connection tracking on UDP packets, so make some test to see if it's doable.
Same here. A (src, sourceport, dst, dstport) tuple uniquely identifies a connection. If you change something in this tuple, it is, by definition, a new one.
Hi all,
Quoted 34 lines · Julien Vehent
Quoted 4 lines · Diego Casado Mansilla
Hello all!!!
This is my first mail in the list.
Quoted 10 lines
Hopefully the question is interesting and you can figure out how to help me.
I use iptables rules to manage the connections from internet to my local network. I know how to filter, do nat, etc...
But this days I'm trying to do NAT in connections that are already established. The problem is (as far as I know) the packets which pass throught the nat table are only the SYN packets (once), thus, the packets that are used to perform a NEW connection.After that the connection is created, the maintenance and the resolution of the SNAT and DNAT are kept till the connection finish.
What I'm wondering is: how can I change the ports or IPs of an already established connection if my packets just go throught the nat table at the connection time?What you want is to redirect an existing connection to a new destination. If you use TCP protocol, the only way to do that is to record the current connection and, in parralel, create a second connection to you new destination and replay the payload on the packet in the new one.
If you use UDP, this doesn't apply since there's no connection tracking in the UDP protocol. Netfilter, however, does some connection tracking on UDP packets, so make some test to see if it's doable.
I had to solve the same problem in a honeypot project to redirect active connections from low interaction honeypots to high interactions honeypots. The solution I choosed was to queue the connections in userland using
netfilter_queue, process them and replay those I've selected to the new destination in parrallel, and then drop the packet from the initial connection.
Quoted 3 lines
It's tricky to do, and there's many issue to solve, but AFAIK this is the most reliable solution.
I have also thought in that solution (or something like that), but I was expecting something easier with iptables-conntrack... :o).
So what I will do is to create a new connection between a C'/S' in my local machine, and when a packet from the real Server go trouhgt my transparent-proxi, I will enqueue it, record the pay-load, do something "tricky" with the ack and seq. number (I think that a substraction should be enought) and use all this stuff to send the data from S' to the Real Client...
After that the client replies with an ACK to the real server...thus.. I have to do a replication of that ACK in order to send one copy to the real Server and annother one to the S' in order to keep the TCP-connection state and flow control. So...Do I must to use annother time the QUEUE to do so?? I think so.
Quoted 51 lines
Quoted 3 lines
**** Maybe doing packets' replication since those ones are redirected to annother machine?
Note : window-tracking is for the tracking of the window size in the tcp header, it has nothing to do with this.
Quoted 7 lines
**** NAT TCP Extensions??Patch-O-Matic --> window-tracking??
**** I read this in an interntet site:
--- NEW (and RELATED non-icmp)
This is a very important part relevant for understanding the wholeNAT
Quoted 11 lines
subsystem. Only if the packet has the state NEW (i.e. it would establish
a new connection, if we'd accept it), the NAT table is traversed by calling ip_nat_rule.c:ip_nat_rule_find(), which in turn calls ip_tables.c:ipt_do_table() for the actual IP table traversal. The
traversal
ends up in either ACCEPTing the packet as it is, or one of the nat
targets
(SNAT, DNAT and if loaded: REDIRECT, MASQUERADE) Please see chapter FIXME for further description of those targets.Quoted 3 lines
--- ESTABLISHED
This packet belongs to an already established connection. We don'tneed
Quoted 4 lines
to traverse the NAT table again, as the necessary information (struct
ip_nat_info) was already gained Hello everybody,Quoted 10 lines
Thank you very much in advance and if my questions are not clear don't doubt to send me a message.
Diego.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 4 lines
Regards,
Julien
Thanks and regards,
Diego.
Hi,
Quoted 11 lines · Diego Casado Mansilla
Hi all,
Quoted 8 lines · Julien Vehent
Quoted 5 lines · Diego Casado Mansilla
Hello all!!!
This is my first mail in the list.
Hopefully the question is interesting and you can figure out how to
help
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
me.
I use iptables rules to manage the connections from internet to my
local
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
network. I know how to filter, do nat, etc...
But this days I'm trying to do NAT in connections that are already established. The problem is (as far as I know) the packets which pass throught the nat table are only the SYN packets (once), thus, the packets that are used to perform a NEW connection.After that the connection is created, the maintenance and the
resolution
Quoted 9 lines
Quoted 9 lines
Quoted 7 lines
of the SNAT and DNAT are kept till the connection finish. What I'm wondering is: how can I change the ports or IPs of an already established connection if my packets just go throught the nat table at the connection time?
What you want is to redirect an existing connection to a new
destination.
Quoted 1 line
Quoted 1 line
If you use TCP protocol, the only way to do that is to record the
current
Quoted 17 lines
Quoted 17 lines
connection and, in parralel, create a second connection to you new destination and replay the payload on the packet in the new one.
If you use UDP, this doesn't apply since there's no connection tracking in
the UDP protocol. Netfilter, however, does some connection tracking on UDP
packets, so make some test to see if it's doable.I had to solve the same problem in a honeypot project to redirect active connections from low interaction honeypots to high interactions honeypots.
The solution I choosed was to queue the connections in userland usingnetfilter_queue, process them and replay those I've selected to the new destination in parrallel, and then drop the packet from the initial connection.
Quoted 1 line
Quoted 1 line
It's tricky to do, and there's many issue to solve, but AFAIK this is
the
Quoted 11 lines
Quoted 2 lines
most reliable solution.
I have also thought in that solution (or something like that), but I was expecting something easier with iptables-conntrack... :o). So what I will do is to create a new connection between a C'/S' in my local machine, and when a packet from the real Server go trouhgt my transparent-proxi, I will enqueue it, record the pay-load, do something "tricky" with the ack and seq. number (I think that a substraction should be enought) and use all this stuff to send the data from S' to the Real Client...
Quoted 5 lines
After that the client replies with an ACK to the real server...thus.. I have to do a replication of that ACK in order to send one copy to the real Server and annother one to the S' in order to keep the TCP-connection state and flow control.
So...Do I must to use annother time the QUEUE to do so?? I think so.
It's even more tricky than this, because if you wait for the ACK of the client, the delay may be too long and you will receive retries from the new server. So you need to ack this packet before you forward it, and then drop the real ack received.
Also, this needs to be done using raw packets, because you will have to manipulate all the header. So, to make it short, you will have to code an almost complete TCP/IP stack to use in your queue...
Have fun !
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
**** Maybe doing packets' replication since those ones are redirected
to
Quoted 52 lines
Quoted 52 lines
Quoted 3 lines
annother machine?
Note : window-tracking is for the tracking of the window size in the tcp header, it has nothing to do with this.
Quoted 7 lines
**** NAT TCP Extensions??Patch-O-Matic --> window-tracking??
**** I read this in an interntet site:
--- NEW (and RELATED non-icmp)
This is a very important part relevant for understanding the wholeNAT
Quoted 11 lines
subsystem. Only if the packet has the state NEW (i.e. it would establish
a new connection, if we'd accept it), the NAT table is traversed by calling ip_nat_rule.c:ip_nat_rule_find(), which in turn calls ip_tables.c:ipt_do_table() for the actual IP table traversal. The
traversal
ends up in either ACCEPTing the packet as it is, or one of the nat
targets
(SNAT, DNAT and if loaded: REDIRECT, MASQUERADE) Please see chapter FIXME for further description of those targets.Quoted 3 lines
--- ESTABLISHED
This packet belongs to an already established connection. We don'tneed
Quoted 15 lines
to traverse the NAT table again, as the necessary information (struct
ip_nat_info) was already gained Hello everybody,Thank you very much in advance and if my questions are not clear don't doubt to send me a message.
Diego.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 7 lines
Quoted 4 lines
Regards,
JulienThanks and regards,
Diego.
Regards,
Julien
Signature · 1 line
www.linuxwall.info
Hi all,
Quoted 80 lines · Julien Vehent
Hi,
Quoted 14 lines · Diego Casado Mansilla
Hi all,
Quoted 10 lines · Julien Vehent
Quoted 6 lines · Diego Casado Mansilla
Hello all!!!
This is my first mail in the list.
Hopefully the question is interesting and you can figure out how to
help
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
me.
I use iptables rules to manage the connections from internet to my
local
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
network. I know how to filter, do nat, etc...
But this days I'm trying to do NAT in connections that are already established. The problem is (as far as I know) the packets which pass throught the nat table are only the SYN packets (once), thus, the packets that are used to perform a NEW connection.After that the connection is created, the maintenance and the
resolution
Quoted 7 lines
Quoted 7 lines
Quoted 5 lines
of the SNAT and DNAT are kept till the connection finish.
What I'm wondering is: how can I change the ports or IPs of an already established connection if my packets just go throught the nat table at the connection time?What you want is to redirect an existing connection to a new
destination.
Quoted 2 lines
Quoted 2 lines
If you use TCP protocol, the only way to do that is to record the
current
Quoted 17 lines
Quoted 17 lines
connection and, in parralel, create a second connection to you new destination and replay the payload on the packet in the new one.
If you use UDP, this doesn't apply since there's no connection tracking in
the UDP protocol. Netfilter, however, does some connection tracking on UDP
packets, so make some test to see if it's doable.I had to solve the same problem in a honeypot project to redirect active connections from low interaction honeypots to high interactions honeypots.
The solution I choosed was to queue the connections in userland usingnetfilter_queue, process them and replay those I've selected to the new destination in parrallel, and then drop the packet from the initial connection.Quoted 2 lines
Quoted 2 lines
It's tricky to do, and there's many issue to solve, but AFAIK this is
the
Quoted 9 lines
Quoted 3 lines
most reliable solution.
I have also thought in that solution (or something like that), but I was expecting something easier with iptables-conntrack... :o).
So what I will do is to create a new connection between a C'/S' in my local machine, and when a packet from the real Server go trouhgt my transparent-proxi, I will enqueue it, record the pay-load, do something "tricky" with the ack and seq. number (I think that a substraction should be enought) and use all this stuff to send the data from S' to the Real Client...After that the client replies with an ACK to the real server...thus.. I have to do a replication of that ACK in order to send one copy to the real Server and annother one to the S' in order to keep the TCP-connection state and flow control. So...Do I must to use annother time the QUEUE to do so?? I think so.
Quoted 10 lines
It's even more tricky than this, because if you wait for the ACK of the client, the delay may be too long and you will receive retries from the new server. So you need to ack this packet before you forward it, and then drop the real ack received.
Also, this needs to be done using raw packets, because you will have to manipulate all the header. So, to make it short, you will have to code an almost complete TCP/IP stack to use in your queue...
Bufff....sounds interesting. But I think there's something that I don't get very well. Outline:
** C-S Connection "sockets TCP".
** Proxi store the connection info (iptables FORWARD -j QUEUE) ** Proxi wants to replace Server, so, a new TCP Connexion is
created locally C'/S'.
** C wants a content, hence, socket C -->recv();
** S-->send(content); proxi catchs payload and drops.
** S' do send with new payload (new port, IP, ack, seq). And obviously C' do nothing.
** C receives the content, since It wants to ACK to S, then it
send ACK.(S doesn't realize their packets are drop)
** Also S' wants the ACK...to maintain both flow control.
So.....I don't understand very well the raw packets
that you has suggested me.
I was thinking to get the ack reply and a the same
trick as before with the original payload.
Do you suggest me to create myself a new ack packet
in my local machine to ACK the content what S' has sent?
Raw packets.....The kernel doesn't process them and I
can create my own IP/TCP headers, isn't it?
To summarize...one Client-2 servers, nobody knows who is in
communication with whom, but the flow control is maintained.
Thanks.
Quoted 74 lines
Have fun !
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
**** Maybe doing packets' replication since those ones are redirected
to
Quoted 54 lines
Quoted 54 lines
Quoted 3 lines
annother machine?
Note : window-tracking is for the tracking of the window size in the tcp header, it has nothing to do with this.
Quoted 8 lines
**** NAT TCP Extensions??Patch-O-Matic --> window-tracking??
**** I read this in an interntet site:
--- NEW (and RELATED non-icmp)
This is a very important part relevant for understanding the wholeNAT
Quoted 11 lines
subsystem. Only if the packet has the state NEW (i.e. it would establish
a new connection, if we'd accept it), the NAT table is traversed by calling ip_nat_rule.c:ip_nat_rule_find(), which in turn calls ip_tables.c:ipt_do_table() for the actual IP table traversal. The
traversal
ends up in either ACCEPTing the packet as it is, or one of the nat
targets
(SNAT, DNAT and if loaded: REDIRECT, MASQUERADE) Please see chapter FIXME for further description of those targets.Quoted 4 lines
--- ESTABLISHED
This packet belongs to an already established connection. We don'tneed
Quoted 15 lines
to traverse the NAT table again, as the necessary information (struct
ip_nat_info) was already gained Hello everybody,Thank you very much in advance and if my questions are not clear don't doubt to send me a message.
Diego.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.htmlQuoted 9 lines
Quoted 5 lines
Regards,
JulienThanks and regards,
Diego.
Quoted 6 lines
Regards,
Julien
Regards,
Diego.