I am trying to direct traffic going to port 2222 to port 443.

Basically, i would like inbound traffic to come into 2222 or 443 and
always be directed to 443. I am doing this because the 3rd party
application I am using only allows it to be listen on one port. So I
am using port 443 for that and want to use iptables as a workaround to
this limitation of the application using only one port.


Server is CentOS 5.1.

What i did:
1. downloaded and installed webmin (because i couldnt get it to work
manually configuring IPTABLES file)
2. allowed inbound traffic to tcp port 2222
3. set up PREROUTING policy to route 2222 to 443
4. service iptables restart
5. tested it by "telnet localhost 2222" fails. "telnet (ip of server)
2222" fails

here is the entire iptables file

# Generated by iptables-save v1.3.5 on Tue Feb 19 21:53:40 2008
*filter
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p esp -j ACCEPT
-A RH-Firewall-1-INPUT -p ah -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp -d 224.0.0.251 --dport 5353 -j
ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 2222 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 10000 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state -m tcp --dport 22 --state NEW -
j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT

# Generated by webmin
*mangle
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Completed
# Generated by webmin
*nat
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -p tcp -m tcp --dport 2222 -j REDIRECT --to-ports 443
COMMIT
# Completed

In <ae043c69-3a66-42b7-a745-771562b74f6b@h1g2000prh.googlegroups.com>, stevehunter_1@hotmail.com wrote:
>I am trying to direct traffic going to port 2222 to port 443.
>
>Basically, i would like inbound traffic to come into 2222 or 443 and
>always be directed to 443. I am doing this because the 3rd party
>application I am using only allows it to be listen on one port. So I
>am using port 443 for that and want to use iptables as a workaround to
>this limitation of the application using only one port.
>
>
>Server is CentOS 5.1.
>
>What i did:
>1. downloaded and installed webmin (because i couldnt get it to work
>manually configuring IPTABLES file)
>2. allowed inbound traffic to tcp port 2222
>3. set up PREROUTING policy to route 2222 to 443
>4. service iptables restart
>5. tested it by "telnet localhost 2222" fails. "telnet (ip of server)
>2222" fails

I'm not sure but I think PREROUTING chain is not consulted for locally generated
packets. So test your rule from some other box or add that rule to OUTPUT chain
also.

HTH
--
·-- ·- ···· ·--- ·- ···- ·- ·--·-· --· -- ·- ·· ·-·· ·-·-·- -·-· --- --

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkiDsxYACgkQHy+EEHYuXnQnXACeNa5HfEf5Yw j59k2FRi01MyzV
w78An2uw3YqIiW6kEqzF9cidLbqgLb4k
=JcY+
-----END PGP SIGNATURE-----

I did try that and unfortunately it also fails ...

So it also does not work from another box. Not sure what the OUTPUT
chain is, but if I tested from another box and it fails, then I think
prerouting is just not working for some reason?

I have tried setting specifics like -i eth0 -d (ip address) on the
various policies... did not help.

There were 2 NICs, the 2nd wasnt used, i even removed that so it is
just eth0 now.

still, no success.

to confirm, also, port 443 is working just fine .. so it is prerouting
issue i am pretty sure. maybe webmin does not configure it precisely
and there needs to be some changes ?


> I'm not sure but I think PREROUTING chain is not consulted for locally generated
> packets. So test your rule from some other box or add that rule to OUTPUTchain
> also.
>
> HTH
> --
> ·-- ·- ···· ·--- ·- ···- ·- ·--·-· --· --·- ·· ·-·· ·-·-·- -·-· --- --
>
> *application_pgp-signature_part
> 1KDownload- Hide quoted text -
>
> - Show quoted text -

In <1a7cf3f3-34fa-44d3-a291-cad5088a161f@s21g2000prm.googlegroups.com>, stevehunter_1@hotmail.com wrote:
>I did try that and unfortunately it also fails ...
>
>So it also does not work from another box. Not sure what the OUTPUT
>chain is, but if I tested from another box and it fails, then I think
>prerouting is just not working for some reason?
>
>I have tried setting specifics like -i eth0 -d (ip address) on the
>various policies... did not help.
>
>There were 2 NICs, the 2nd wasnt used, i even removed that so it is
>just eth0 now.
>
>still, no success.
>
>to confirm, also, port 443 is working just fine .. so it is prerouting
>issue i am pretty sure. maybe webmin does not configure it precisely
>and there needs to be some changes ?

Then try logging iptables rules, by inserting entries with LOG target also,to
be sure.

HTH
--
·-- ·- ···· ·--- ·- ···- ·- ·--·-· --· -- ·- ·· ·-·· ·-·-·- -·-· --- --

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkiESQMACgkQHy+EEHYuXnSzpACcDAYoEZkqf+ koeIyNz4VuMxRW
IyQAn2Te1zNDvSiWDizcVEK0ASJWl619
=r453
-----END PGP SIGNATURE-----

Ok, here is what has happened:

i have been testing trying to connect to port 2222 via our VPN (which
i certainly should be able to).

When I connect from the outside world to the WAN IP:2222 it works
perfectly.

When I connect from VPN to LANIP:2222 it does not work (also does not
work on the server directly).

any ideas on why it does not work?

the VPN is like one server connecting to another server on a LAN. i
think it is not a VPN security issue .......
LOG shows nothing for VPN. too strange

Add the LOG rules as suggested to confirm the traffic is being processed
properly, and try DNAT instead of the REDIRECT target in both the
PREROUTING and OUTPUT chains.