Port Fowarding Between Cisco 678 and Linux IPTables

I am having trouble getting port forwarding to work for some ports
through a nat'ed cisco/iptables topology.

Example:

[Internet] <-----> [Cisco 678 (NAT)] <-----> [Linux IPTables (NAT)]
<-----> [Local Network]

Cisco external interface is wan0-0 and ip is dynamic
Cisco internal interface is eth0 and ip is 192.168.1.1

Linux external interface is eth0 and ip is 192.168.1.2
Linux internal interface eth1 and ip is 192.168.0.1

Local Network subnet 192.168.0.0/24

Preforming a port scan from the Internet against the Cisco public ip
address yields 2 open ports:

23/telnet
80/http

I configure the Cisco to port forward using the following NAT rule:

set nat entry add 192.168.1.2 22 tcp

Preforming a port scan from the Internet against the Cisco public ip
address then yields 3 open ports:

22/ssh
23/telnet
80/http

I can then configure the Linux IPTables to port forward the ssh
connection to another internal box with:

Linux external interface is eth0 and ip is 192.168.1.2
Linux internal interface eth1 and ip is 192.168.0.1

daemon /sbin/iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 22 -m
state --state NEW,ESTABLISHED,RELATED -j ACCEPT

daemon /sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 22 -j
DNAT --to 192.168.0.15:22

This works great!

Now... When I try to do the same thing with say 3389/rdp, I am never
able to scan port 3389 open on the Cisco public ip address. I have
tried several ports (25, 110, 143, 6000) with negative results.

If I scan the local network pc with these services, I am able to detect
that they are open.

Any idea as to why port 22/ssh will forward, but I can't get other
ports like 3389/rdp to work?

Thank you for your assistance.

Respectfully,


Gary

(E-Mail Removed) wrote:
> I am having trouble getting port forwarding to work for some ports
> through a nat'ed cisco/iptables topology.
>
> Example:
>
> [Internet] <-----> [Cisco 678 (NAT)] <-----> [Linux IPTables (NAT)]
> <-----> [Local Network]
>
> Cisco external interface is wan0-0 and ip is dynamic
> Cisco internal interface is eth0 and ip is 192.168.1.1
>
> Linux external interface is eth0 and ip is 192.168.1.2
> Linux internal interface eth1 and ip is 192.168.0.1
>
> Local Network subnet 192.168.0.0/24
>
> Preforming a port scan from the Internet against the Cisco public ip
> address yields 2 open ports:
>
> 23/telnet
> 80/http
>
> I configure the Cisco to port forward using the following NAT rule:
>
> set nat entry add 192.168.1.2 22 tcp
>
> Preforming a port scan from the Internet against the Cisco public ip
> address then yields 3 open ports:
>
> 22/ssh
> 23/telnet
> 80/http
>
> I can then configure the Linux IPTables to port forward the ssh
> connection to another internal box with:
>
> Linux external interface is eth0 and ip is 192.168.1.2
> Linux internal interface eth1 and ip is 192.168.0.1
>
> daemon /sbin/iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 22 -m
> state --state NEW,ESTABLISHED,RELATED -j ACCEPT
>
> daemon /sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 22 -j
> DNAT --to 192.168.0.15:22
>
> This works great!
>
> Now... When I try to do the same thing with say 3389/rdp, I am never
> able to scan port 3389 open on the Cisco public ip address. I have
> tried several ports (25, 110, 143, 6000) with negative results.
>
> If I scan the local network pc with these services, I am able to detect
> that they are open.
>
> Any idea as to why port 22/ssh will forward, but I can't get other
> ports like 3389/rdp to work?

Hi,

Are you doing the port scan on cisco after adding the nat entry(3389)
but without the corresponding iptables entry in Linux ???

In which case I would suggest you set nat entry for 3389(router) and
also enable the DNAT and FORWARD for 3389(Linux) just as you did before
for SSH and then try.

It should work. Why did it work with SSH even before iptables then????
That's because I presume you would have had the SSH port open on the
Linux box by default but not the others like 3389, smtp etc. A
succesful portscan must have a complete path to the destination port.
If you just put the nat entry it will scan your linux box for 3389
which will fail unless correctly DNATted.

Also from what I observe you should have a reverse entry also in the
FORWARD chain unless your policy is set to ACCEPT in which case you
dont need the FORWARD entry at all. In general it's better to use a
DROP policy in the filter table chains and allow explicitly.

(E-Mail Removed) wrote:
> I am having trouble getting port forwarding to work for some ports
> through a nat'ed cisco/iptables topology.
>
> Example:
>
> [Internet] <-----> [Cisco 678 (NAT)] <-----> [Linux IPTables (NAT)]
> <-----> [Local Network]

One thing that you might consider is to upgrade your 678, if it needs it.

G'luck....


--
PLEASE post a SUMMARY of the answer(s) to your question(s)!
Show Windows & Gates to the exit door.
Unless otherwise noted, the statements herein reflect my personal
opinions and not those of any organization with which I may be affiliated.

> Are you doing the port scan on cisco after adding the nat entry(3389)
> but without the corresponding iptables entry in Linux ???

I have tried both ways and they all give me negative results except
22/ssh.

> It should work. Why did it work with SSH even before iptables then????
> That's because I presume you would have had the SSH port open on the
> Linux box by default but not the others like 3389, smtp etc.

I had the same thought and that is the reason I tried the other ports.
The
Linux box with IPTables has ports 25, 110, 143, and 6000 open. Non of
them showed as open from the Internet when forwarded on the Cisco.

I did find that without the IPTables rules, 22/ssh was being forwarded
to the
Linux box with IPTables and when I added IPTables rules for 22/ssh to
another machine on the Local Network it successfully port forwarded to
that
internal machine from out on the Internet. I just can't get it to work
with ports
other than 22/ssh.

> Also from what I observe you should have a reverse entry also in the
> FORWARD chain unless your policy is set to ACCEPT in which case you
> dont need the FORWARD entry at all. In general it's better to use a
> DROP policy in the filter table chains and allow explicitly.

Here are my IPTables policies without the forwarding rules.

Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere state
RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere tcp dpt:x11
state NEW,RELATED,ESTABLISHED
LOG all -- anywhere anywhere LOG level
warning

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Thank you for the execellent advice. Do you have any other ideas?

Respectfully,


Gary

I believe I have narrowed down the issue even further.

Using tcpdump, I captured the rdp packets being sent by a remote
computer on the Internet.

18:13:29.155444 internetclient.59050 > linuxgateway.ms-wbt-server: S
[tcp sum ok] 177779647:177779647(0) win 5840 <mss 1460,sackOK,timestamp
32063710 0,nop,wscale 0> (DF) (ttl 64, id 36583, len 60)
18:13:41.155635 internetclient.59050 > linuxgateway.ms-wbt-server: S
[tcp sum ok] 177779647:177779647(0) win 5840 <mss 1460,sackOK,timestamp
32064910 0,nop,wscale 0> (DF) (ttl 64, id 36584, len 60)
18:14:05.155953 internetclient.59050 > linuxgateway.ms-wbt-server: S
[tcp sum ok] 177779647:177779647(0) win 5840 <mss 1460,sackOK,timestamp
32067310 0,nop,wscale 0> (DF) (ttl 64, id 36585, len 60)

This demonstraights that rdp packets are being sent out, but are never
returned.

Using tcpdump, I then captured the rdp packets as they came off of the
internal interface of the Cisco and on to the external interface of the
LInux Gateway (IPTables).

18:14:53.218659 internetclient.59050 > 192.168.1.2.3389: S [tcp sum ok]
177779647:177779647(0) win 5840 <mss 1460,sackOK,timestamp 32072110
0,nop,wscale 0> (DF) (ttl 59, id 36586, len 60)
18:14:53.219426 192.168.1.2.3389 > internetclient.59050: S [tcp sum ok]
755755903:755755903(0) ack 177779648 win 17520 <mss 1460,nop,wscale
0,nop,nop,timestamp 0 0,nop,nop,sackOK> (DF) (ttl 127, id 39646, len
64)
18:14:53.319641 internetclient.59050 > 192.168.1.2.3389: R [tcp sum ok]
177779648:177779648(0) win 0 (DF) (ttl 250, id 0, len 40)

This demonstraights that rdp packets are being received from the remote
computer on the Internet, but the source computer is sending a RESET (I
assume because of no response).

Using tcpdump, I then captured the rdp packets as the left the internal
interface of the Linux Gateway (IPTables) and towards its destonation
of the Local Network Computer with RDP.

18:14:05.203261 internetclient.59050 > 192.168.0.13.3389: S [tcp sum
ok] 177779647:177779647(0) win 5840 <mss 1460,sackOK,timestamp 32067310
0,nop,wscale 0> (DF) (ttl 58, id 36585, len 60)
18:14:05.203684 192.168.0.13.3389 > internetclient.59050: S [tcp sum
ok] 743438116:743438116(0) ack 177779648 win 17520 <mss 1460,nop,wscale
0,nop,nop,timestamp 0 0,nop,nop,sackOK> (DF) (ttl 128, id 39453, len
64)
18:14:05.304168 internetclient.59050 > 192.168.0.13.3389: R [tcp sum
ok] 177779648:177779648(0) win 0 (DF) (ttl 249,
id 0, len 40)

This also demonstraights that rdp packets are being received from the
remote computer on the Internet, but again the source computer is
sending a RESET to the Local Network Computer.

Using Ethereal, I found the same results between the Internet Computer
and the Local Network, and when the Internet Computer sends the RESET
Ethereal displays a TCP ZeroWindow flag.

>From my tests, it appears that the originating rdp packets are getting
to the Local Network Computer that has the RDP service on it, but for
some reason the responses are not making their way back.

I have tried a few POSTROUTING filters, but none seem to remedy the
issue.

Your advice would be greatly appreciated.

Respectfully,


Gary

(E-Mail Removed) wrote:
> I believe I have narrowed down the issue even further.
>
> Using tcpdump, I captured the rdp packets being sent by a remote
> computer on the Internet.
>
> 18:13:29.155444 internetclient.59050 > linuxgateway.ms-wbt-server: S
> [tcp sum ok] 177779647:177779647(0) win 5840 <mss 1460,sackOK,timestamp
> 32063710 0,nop,wscale 0> (DF) (ttl 64, id 36583, len 60)
> 18:13:41.155635 internetclient.59050 > linuxgateway.ms-wbt-server: S
> [tcp sum ok] 177779647:177779647(0) win 5840 <mss 1460,sackOK,timestamp
> 32064910 0,nop,wscale 0> (DF) (ttl 64, id 36584, len 60)
> 18:14:05.155953 internetclient.59050 > linuxgateway.ms-wbt-server: S
> [tcp sum ok] 177779647:177779647(0) win 5840 <mss 1460,sackOK,timestamp
> 32067310 0,nop,wscale 0> (DF) (ttl 64, id 36585, len 60)
>
> This demonstraights that rdp packets are being sent out, but are never
> returned.
>
> Using tcpdump, I then captured the rdp packets as they came off of the
> internal interface of the Cisco and on to the external interface of the
> LInux Gateway (IPTables).
>
> 18:14:53.218659 internetclient.59050 > 192.168.1.2.3389: S [tcp sum ok]
> 177779647:177779647(0) win 5840 <mss 1460,sackOK,timestamp 32072110
> 0,nop,wscale 0> (DF) (ttl 59, id 36586, len 60)
> 18:14:53.219426 192.168.1.2.3389 > internetclient.59050: S [tcp sum ok]
> 755755903:755755903(0) ack 177779648 win 17520 <mss 1460,nop,wscale
> 0,nop,nop,timestamp 0 0,nop,nop,sackOK> (DF) (ttl 127, id 39646, len
> 64)
> 18:14:53.319641 internetclient.59050 > 192.168.1.2.3389: R [tcp sum ok]
> 177779648:177779648(0) win 0 (DF) (ttl 250, id 0, len 40)
>
> This demonstraights that rdp packets are being received from the remote
> computer on the Internet, but the source computer is sending a RESET (I
> assume because of no response).

.... and that the response was sent by LInux Gateway.
Maybe you have firewall on this cisco or on/before remote computer?

Jarek P.

> ... and that the response was sent by LInux Gateway.
> Maybe you have firewall on this cisco or on/before remote computer?
>
> Jarek P.

Well... It turned out to be the Cisco 678! As suggested by Jarek and
demonstraighted by the tcpdump's on the Linux Gateway, packets were
being passed through the Linux Gateway but nothing was getting returned
beyond it. The next logical step was to take the Linux Gateway out of
the equasion and have the Cisco peer right into the Local Network.
Once this was done, it was apparent that the issue was not resolved.
After playing around with the Cisco's NAT and Filters, with no success,
I decided to reset it to factory default and reconfigure it. Upon
reconfiguring the Cisco, I was able to add the same NAT rule to it for
3389/rdp and it began forwarding, correctly. I then added the Linux
Gateway back into the mix, with the same IPTables FORWARD and
PREROUTING rules, and everything was finally working as it should!

I don't know what the specific issue was with the Cisco 678 to cause it
to not forward responses, but the fact is port forwarding between a
nat'ed Cisco 678 and Linux Gateway with IPTables--is possible and will
work!

I hope this might be usefull to someone else in the future.

Respectfully,


Gary