iptables/nat need help !

Hi People.

I'm in a despaired need of a IPTABLES guru.

(I'm on two RedHat AS2.1 machines)

Here is my problem.
Basically, I'm trying to set up a client/server application that uses
hard encoded tcp-ports, with a firewall in the middle. Server

listens @TCP:5012 and clients has that destination port of the server
(TCP:5012) hard encoded.
It goes this way : (xxx stands for TCP dynamic ports)

client server
1.1.1.1:xxx ---> 2.2.2.2:5012
talks to : answers to :
2.2.2.2:5012 <--- 1.1.1.1:xxx

Here my client:xxx talks to server:5012 and server:5012 replys to
client:xxx

But, my FireWall allows only tcp:2012 to go through.

So, what I need is IPTABLES -t NAT to remap the ports this way:
client server
1.1.1.1:xxx 2.2.2.2:5012
talks to : answers to :
2.2.2.2:5012 1.1.1.1:xxx
| |
| |
NAT NAT
| |
| FW:2012:OK |
2.2.2.2:2012 ---> 1.1.1.1:xxx
<---

Because of my FireWall, I want my client:xxx to talk to server:2012,
when calling server:5012.
On the client, I need NAT to map (server) DPORT:5012 to DPORT:2012.
---
iptables -t nat -A OUTPUT -p tcp -d 2.2.2.2 --dport 5012 -j DNAT
--to-destination 2.2.2.2:2012
---

On the server side, I need NAT to map (server) DPORT:2012 to DPORT:5012
---
/sbin/iptables -t nat -A PREROUTING -p tcp --dport 2012 -j DNAT --to
2.2.2.2:5012
---


Each side seems to be doing his job but the whole thing is not working.

- Does anyone have any idea ?

TIA
Regards.
Marek

tcpdump trace on the client...

14:39:27.096278 1.1.1.1.58453 > 2.2.2.2.2012: S
1572536637:1572536637(0) win 5840 <mss 1460,nop,wscale 2> (DF)
14:39:27.107736 2.2.2.2.2012 > 1.1.1.1.58453: S 189483614:189483614(0)
ack 1572536638 win 5840 <mss 1460> (DF) [tos 0x68]
14:39:27.107777 1.1.1.1.1146 > 2.2.2.2.2012: R 1572536638:1572536638(0)
win 0 (DF) [tos 0x68]
14:39:29.128014 2.2.2.2.2012 > 1.1.1.1.58451: S 145422812:145422812(0)
ack 1520235486 win 5840 <mss 1460> (DF) [tos 0x68]
14:39:29.128055 1.1.1.1.1146 > 2.2.2.2.2012: R 1520235486:1520235486(0)
win 0 (DF) [tos 0x68]
14:39:30.928095 2.2.2.2.2012 > 1.1.1.1.58453: S 189483614:189483614(0)
ack 1572536638 win 5840 <mss 1460> (DF) [tos 0x68]
14:39:30.928126 1.1.1.1.1146 > 2.2.2.2.2012: R 1572536638:1572536638(0)
win 0 (DF) [tos 0x68]
14:39:36.927818 2.2.2.2.2012 > 1.1.1.1.58453: S 189483614:189483614(0)
ack 1572536638 win 5840 <mss 1460> (DF) [tos 0x68]
14:39:36.927854 1.1.1.1.1146 > 2.2.2.2.2012: R 1572536638:1572536638(0)
win 0 (DF) [tos 0x68]


tcpdump trace on the server...

14:41:11.889333 1.1.1.1.58453 > 2.2.2.2.5012: S
1572536637:1572536637(0) win 5840 <mss 1460,nop,wscale 2> (DF)
14:41:11.889376 2.2.2.2.2012 > 1.1.1.1.58453: S 189483614:189483614(0)
ack 1572536638 win 5840 <mss 1460> (DF)
14:41:11.901075 1.1.1.1.1146 > 2.2.2.2.2012: R 1572536638:1572536638(0)
win 0 (DF) [tos 0x68]
14:41:13.909758 2.2.2.2.2012 > 1.1.1.1.58451: S 145422812:145422812(0)
ack 1520235486 win 5840 <mss 1460> (DF)
14:41:13.921240 1.1.1.1.1146 > 2.2.2.2.2012: R 1520235486:1520235486(0)
win 0 (DF) [tos 0x68]
14:41:15.709749 2.2.2.2.2012 > 1.1.1.1.58453: S 189483614:189483614(0)
ack 1572536638 win 5840 <mss 1460> (DF)
14:41:15.721412 1.1.1.1.1146 > 2.2.2.2.2012: R 1572536638:1572536638(0)
win 0 (DF) [tos 0x68]
14:41:21.709721 2.2.2.2.2012 > 1.1.1.1.58453: S 189483614:189483614(0)
ack 1572536638 win 5840 <mss 1460> (DF)
14:41:21.721571 1.1.1.1.1146 > 2.2.2.2.2012: R 1572536638:1572536638(0)
win 0 (DF) [tos 0x68]

> Marek
>
> tcpdump trace on the client...
>
> 14:39:27.096278 1.1.1.1.58453 > 2.2.2.2.2012: S
> 1572536637:1572536637(0) win 5840 <mss 1460,nop,wscale 2> (DF)
> 14:39:27.107736 2.2.2.2.2012 > 1.1.1.1.58453: S 189483614:189483614(0)
> ack 1572536638 win 5840 <mss 1460> (DF) [tos 0x68]
> 14:39:27.107777 1.1.1.1.1146 > 2.2.2.2.2012: R 1572536638:1572536638(0)
> win 0 (DF) [tos 0x68]
> 14:39:29.128014 2.2.2.2.2012 > 1.1.1.1.58451: S 145422812:145422812(0)
> ack 1520235486 win 5840 <mss 1460> (DF) [tos 0x68]
> 14:39:29.128055 1.1.1.1.1146 > 2.2.2.2.2012: R 1520235486:1520235486(0)
> win 0 (DF) [tos 0x68]
> 14:39:30.928095 2.2.2.2.2012 > 1.1.1.1.58453: S 189483614:189483614(0)
> ack 1572536638 win 5840 <mss 1460> (DF) [tos 0x68]
> 14:39:30.928126 1.1.1.1.1146 > 2.2.2.2.2012: R 1572536638:1572536638(0)
> win 0 (DF) [tos 0x68]
> 14:39:36.927818 2.2.2.2.2012 > 1.1.1.1.58453: S 189483614:189483614(0)
> ack 1572536638 win 5840 <mss 1460> (DF) [tos 0x68]
> 14:39:36.927854 1.1.1.1.1146 > 2.2.2.2.2012: R 1572536638:1572536638(0)
> win 0 (DF) [tos 0x68]
>

There is something strange in this dump. There is actually two different TCP
flow; one using SRC port 58453, another using SRC port 1146.

Any reason why your application would use two different SRC ports ?

>
> tcpdump trace on the server...
>
> 14:41:11.889333 1.1.1.1.58453 > 2.2.2.2.5012: S
> 1572536637:1572536637(0) win 5840 <mss 1460,nop,wscale 2> (DF)
> 14:41:11.889376 2.2.2.2.2012 > 1.1.1.1.58453: S 189483614:189483614(0)
> ack 1572536638 win 5840 <mss 1460> (DF)
> 14:41:11.901075 1.1.1.1.1146 > 2.2.2.2.2012: R 1572536638:1572536638(0)
> win 0 (DF) [tos 0x68]
> 14:41:13.909758 2.2.2.2.2012 > 1.1.1.1.58451: S 145422812:145422812(0)
> ack 1520235486 win 5840 <mss 1460> (DF)
> 14:41:13.921240 1.1.1.1.1146 > 2.2.2.2.2012: R 1520235486:1520235486(0)
> win 0 (DF) [tos 0x68]
> 14:41:15.709749 2.2.2.2.2012 > 1.1.1.1.58453: S 189483614:189483614(0)
> ack 1572536638 win 5840 <mss 1460> (DF)
> 14:41:15.721412 1.1.1.1.1146 > 2.2.2.2.2012: R 1572536638:1572536638(0)
> win 0 (DF) [tos 0x68]
> 14:41:21.709721 2.2.2.2.2012 > 1.1.1.1.58453: S 189483614:189483614(0)
> ack 1572536638 win 5840 <mss 1460> (DF)
> 14:41:21.721571 1.1.1.1.1146 > 2.2.2.2.2012: R 1572536638:1572536638(0)
> win 0 (DF) [tos 0x68]


Seems like you have a SRC port mismatch. 1.1.1.1:1146 receive no reply from
the server.

While the server actually see that traffic:
>14:41:11.901075 1.1.1.1.1146 > 2.2.2.2.2012: R 1572536638:1572536638(0)
> win 0 (DF) [tos 0x68]

There is no reply on this SRC port; the only traffic you get back goes to
SRC port 58453.

If you want NAT to work properly without helper; you need to have consistent
TCP ports during the flow.

I would suggest you investigate your client/server application traffic
between two directly linked host, before playing with NAT.

Once you know exactly how it works; you can build a NAT strategy.

Hope that helps.

Vincent.

--
Kelkoo Security Manager / Networks & Systems Architect
JID: portsentry@jabber.kelkoo.net / Vincent.Jaussaud.AT.kelkoo.DOT.net
Kelkoo.com --- GNU/Linux Powered

Salut Vincent.

>
> There is something strange in this dump. There is actually two
different TCP
> flow; one using SRC port 58453, another using SRC port 1146.
>
> Any reason why your application would use two different SRC ports ?

No. Not any.
And it is not my application that makes those calls.

The source port changes everytime and those calls are still present
some time after I kill my client (+- 1mn). My client is just a simple
Perl tcp client.
I'm getting the same result with a "telnet 2.2.2.2 5012"
The server is a simple Perl tcp server saying "hello..." to whomever
connects.

I don't see those calls unless I mess up with iptables on the client
side.



> Seems like you have a SRC port mismatch. 1.1.1.1:1146 receive no
reply from
> the server.
>

Agreed

> While the server actually see that traffic:
> >14:41:11.901075 1.1.1.1.1146 > 2.2.2.2.2012: R
1572536638:1572536638(0)
> > win 0 (DF) [tos 0x68]
>
> There is no reply on this SRC port; the only traffic you get back
goes to
> SRC port 58453.
>

Agreed

> If you want NAT to work properly without helper; you need to have
consistent
> TCP ports during the flow.
>

Agreed

> I would suggest you investigate your client/server application
traffic
> between two directly linked host, before playing with NAT.
>

Done.

> Once you know exactly how it works; you can build a NAT strategy.
>

It works just fine as far as I don't set up the client IPTABLES's NAT.

If I call directly TCP:2012 "./client.pl 2.2.2.2 2012" with the server
(listening on TCP:5012 and NAT mapping 2012 to 5012) it works just
fine. None other ports implicated than xxx - on the client side and
server says HELLO ! ;-)

Bon, assez d'anglais. Merci pour ta réponse en tout cas.
Je me demande si cela ne vient pas d'un bug dans les IPTABLES.
(??)

Salut.

>
> The source port changes everytime and those calls are still present
> some time after I kill my client (+- 1mn). My client is just a simple
> Perl tcp client.

Got it, so these are just packets from a previous opened connections.

> It works just fine as far as I don't set up the client IPTABLES's NAT.
>
> If I call directly TCP:2012 "./client.pl 2.2.2.2 2012" with the server
> (listening on TCP:5012 and NAT mapping 2012 to 5012) it works just
> fine. None other ports implicated than xxx - on the client side and
> server says HELLO ! ;-)
>

Why do you actually need to do a first NAT on the client, from 5012 to
2012 ? If your firewall allows 2012 to pass through, why don't you just use
it directly ?

I'm not sure to understand what your problem is, actually.

> Bon, assez d'anglais. Merci pour ta réponse en tout cas.
> Je me demande si cela ne vient pas d'un bug dans les IPTABLES.
> (??)

I don't think so; I just tried a similar setup; with 2xDNAT strategy, and it
works fine. Tested with linux 2.4 and 2.6. (Please avoid french on this
newsgroup; your problem may be of some interest for other, non french
people :) )

Cheers,


>
> Salut.

--
Kelkoo Security Manager / Networks & Systems Architect
JID: portsentry@jabber.kelkoo.net / Vincent.Jaussaud.AT.kelkoo.DOT.net
Kelkoo.com --- GNU/Linux Powered

Vincent Jaussaud wrote:

>
> Why do you actually need to do a first NAT on the client, from 5012
to
> 2012 ? If your firewall allows 2012 to pass through, why don't you
just use
> it directly ?
>
> I'm not sure to understand what your problem is, actually.
>

Because, as I said it before, the dest port is hard encoded in the
client.
No way to make him call anything else than tcp:5012.

The main idea is : the server is listening on TCP:5012 and the client
wants to talk to server@TCP:5012. My FWall accepts only TCP:2012. So
I'm looking for a way to redirect the whole traffic through TCP:2012
without making it apparent for the client and the server. Thought
IPTABLES would do the job but, I can't make it work.

If you managed to set it up (the way it is wanted) could you be so kind
and post your iptables directives here...

TIA
Marek

>
> If you managed to set it up (the way it is wanted) could you be so kind
> and post your iptables directives here...

Sure, here you go:

On client:
iptables -t nat -A OUTPUT -p tcp -d 172.24.113.163 --dport 222 -j DNAT
--to-destination 172.24.113.163:2222

On Server:
iptables -t nat -I PREROUTING -p tcp -d 172.24.113.163 --dport 2222 -j DNAT
--to-destination 172.24.113.163:22

Then:
[root@client ]$ ssh -p 222 root@server
root@server's password:
Last login: Mon Feb 7 12:16:24 2005 from localhost.localdomain
[root@server ~]#

On client:
[root@client ]# netstat -tan | grep :222
tcp 0 0 CLIENT_IP_ADDRESS:49101 172.24.113.163:222
ESTABLISHED

[root@client ]# iptables -t nat -L OUTPUT -v
Chain OUTPUT (policy ACCEPT 15450 packets, 1122K bytes)
pkts bytes target prot opt in out source
destination
3 180 DNAT tcp -- any any anywhere server
tcp dpt:222 to:172.24.113.163:2222


On server:
[root@server ~]# netstat -tan | grep :22
tcp 0 0 172.24.113.163:22 CLIENT_IP_ADDRESS:49101
ESTABLISHED

[root@server ~]# iptables -t nat -L PREROUTING -v
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
1 60 DNAT tcp -- any any anywhere server
tcp dpt:2222 to:172.24.113.163:22

Regards,
Vincent.

>
> TIA
> Marek

--
Kelkoo Security Manager / Networks & Systems Architect
JID: portsentry@jabber.kelkoo.net / Vincent.Jaussaud.AT.kelkoo.DOT.net
Kelkoo.com --- GNU/Linux Powered

Still not working for me with the same result.
(??)

Anyway, thanks for your help !

Best Regards.
Marek



Vincent Jaussaud wrote:
> >
> > If you managed to set it up (the way it is wanted) could you be so
kind
> > and post your iptables directives here...
>
> Sure, here you go:
>
> On client:
> iptables -t nat -A OUTPUT -p tcp -d 172.24.113.163 --dport 222 -j
DNAT
> --to-destination 172.24.113.163:2222
>
> On Server:
> iptables -t nat -I PREROUTING -p tcp -d 172.24.113.163 --dport 2222
-j DNAT
> --to-destination 172.24.113.163:22
>
> Then:
> [root@client ]$ ssh -p 222 root@server
> root@server's password:
> Last login: Mon Feb 7 12:16:24 2005 from localhost.localdomain
> [root@server ~]#
>
> On client:
> [root@client ]# netstat -tan | grep :222
> tcp 0 0 CLIENT_IP_ADDRESS:49101
172.24.113.163:222
> ESTABLISHED
>
> [root@client ]# iptables -t nat -L OUTPUT -v
> Chain OUTPUT (policy ACCEPT 15450 packets, 1122K bytes)
> pkts bytes target prot opt in out source
> destination
> 3 180 DNAT tcp -- any any anywhere
server
> tcp dpt:222 to:172.24.113.163:2222
>
>
> On server:
> [root@server ~]# netstat -tan | grep :22
> tcp 0 0 172.24.113.163:22 CLIENT_IP_ADDRESS:49101
> ESTABLISHED
>
> [root@server ~]# iptables -t nat -L PREROUTING -v
> Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
> pkts bytes target prot opt in out source
> destination
> 1 60 DNAT tcp -- any any anywhere
server
> tcp dpt:2222 to:172.24.113.163:22
>
> Regards,
> Vincent.
>
> >
> > TIA
> > Marek
>
> --
> Kelkoo Security Manager / Networks & Systems Architect
> JID: portsentry@jabber.kelkoo.net /
Vincent.Jaussaud.AT.kelkoo.DOT.net
> Kelkoo.com --- GNU/Linux Powered