Port Redirection

Port Redirection

[ABOKHALAF, Nassri Abdellatif]

Hello to all,

I need to redirect some services to my ssh port.
my firewall has two interfaces and i want to redirect all traffic to port 22,
so i added this code to my firewall script

....initialisation code....

My_PORTS_TCP="22 ftp telnet squid socks kazaa back_or"

echo -n "TCP port "
for i in $My_PORTS_TCP;
do
        echo -n "$i "
        $IPT -t nat -A PREROUTING -p TCP -d $EXTNET --dport $i -j REDIRECT --to-ports  22

        fi
done

but when i do tcpdump to port 22 i see no traffic at all, although i am doing ftp to my firewall !?!
questions:
1-Is the rule wrong ?
2-Is the tcpdump leastning in a raw socket before redirection ?
3-How can i confirm that redirection is functioning ?

please comment,


nassri

Port Redirection

[nassri abokhalaf]

Hello to all,

I need to redirect some services to my ssh port.
my firewall has two interfaces and i want to redirect all traffic to port 22,
so i added this code to my firewall script

...initialisation code....

My_PORTS_TCP="22 ftp telnet squid socks kazaa back_or"

echo -n "TCP port "
for i in $My_PORTS_TCP;
do
        echo -n "$i "
        $IPT -t nat -A PREROUTING -p TCP -d $EXTNET --dport $i -j REDIRECT --to-ports  22

        fi
done

but when i do tcpdump to port 22 i see no traffic at all, although i am doing ftp to my firewall !?!
questions:
1-Is the rule wrong ?
2-Is the tcpdump leastning in a raw socket before redirection ?
3-How can i confirm that redirection is functioning ?

please comment,


nassri

Port redirection

[Chris NoSurname]

Hi all.

I've searched and searched and I cannot seem to get
this working.

I'm trying to redirect port 80 to a different port so
that I can run the Resin application server as
non-root user.  I've got the following command..

iptables -t nat -A PREROUTING -p tcp --dport 80 -d
x.x.x.x -j REDIRECT --to-ports 8900

It comes up as 

    0     0 REDIRECT   tcp  --  any    any    
anywhere             www.mydomain.com   tcp dpt:http
redir ports 8900

Yet, if I connect to the http port it is closed.  Port
8900 is open and does accept connections if I specify
it in the address.

I am unclear of why the rules shows up in status, but
does not work.

Thanks for any help you can offer.

David

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

RE: Port redirection

[Anthony Sadler]

Hey Chris:

My rule I use for transparent proxy is this:

iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT
--to-port 3128 

I notice you have set "--to-ports" (ie plural). I'm not sure if that will
work. Some others could comment better than I.

Thanks

Anthony

-----Original Message-----
From: netfilter-bounces@lists.netfilter.org
[mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of Chris NoSurname
Sent: Wednesday, 1 June 2005 5:25 AM
To: netfilter@lists.netfilter.org
Subject: Port redirection

Hi all.

I've searched and searched and I cannot seem to get this working.

I'm trying to redirect port 80 to a different port so that I can run the
Resin application server as non-root user.  I've got the following command..

iptables -t nat -A PREROUTING -p tcp --dport 80 -d x.x.x.x -j REDIRECT
--to-ports 8900

It comes up as 

    0     0 REDIRECT   tcp  --  any    any    
anywhere             www.mydomain.com   tcp dpt:http
redir ports 8900

Yet, if I connect to the http port it is closed.  Port 8900 is open and does
accept connections if I specify it in the address.

I am unclear of why the rules shows up in status, but does not work.

Thanks for any help you can offer.

David

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 

Re: Port redirection

[Taylor, Grant]

> I notice you have set "--to-ports" (ie plural). I'm not sure if that will
> work. Some others could comment better than I.

"--to-ports" (plural) is correct for the REDIRECT target.



Grant. . . .

Re: Port redirection

[Jason Opperisano]

On Tue, May 31, 2005 at 12:25:03PM -0700, Chris NoSurname wrote:
> Hi all.
> 
> I've searched and searched and I cannot seem to get
> this working.
> 
> I'm trying to redirect port 80 to a different port so
> that I can run the Resin application server as
> non-root user.  I've got the following command..
> 
> iptables -t nat -A PREROUTING -p tcp --dport 80 -d
> x.x.x.x -j REDIRECT --to-ports 8900

if resin is not listening on $INBOUND_IF_IP:8900; or more realistically
0.0.0.0:8900, then it wouldn't work.  REDIRECT rewrites the dst IP to be
the IP of the receiving interface, since you don't even have an "-i $IF"
specified in that rule, resin would have to be listening on 0.0.0.0:8900
to even have a shot at working properly (or the machine in question
only has a single interface, perhaps?).

-j

--
"Peter: We love the Bible in this house.
 Francis: Really. What's your favorite book of the Bible?
 Peter: Uhhhhh... the book where Jesus swallows the puzzle piece and
 the man in the yellow hat has to take him to the hospital."
        --Family Guy

port redirection

[Brian Lewis]

I run a servlet container that wants to listen on TCP 8080. I want to
redirect TCP 80 on my machine to 8080 on the same machine.

If I do -t nat -I PREROUTING -i $IF -d $IP -p tcp --dport 80 -j REDIRECT
--to-port 8080, it works in that I reach the 8080 server when I connect
to 80.

But I have to allow 8080 through. Is there a way to provide access to the
8080 server via port 80 without having to allow 8080?

Stating the problem a different way, suppose that for security through
obscurity purposes you wanted sshd to appear as if it was running on 2200
via firewall rules. The above method of redirecting 2200 -> 22 would work,
but not offer much help because 22 would still have to be open.

Thank you.

Re: port redirection

[Graham Murray]

Brian Lewis <bsl04@uark.edu> writes:

> I run a servlet container that wants to listen on TCP 8080. I want to
> redirect TCP 80 on my machine to 8080 on the same machine.
>
> If I do -t nat -I PREROUTING -i $IF -d $IP -p tcp --dport 80 -j REDIRECT
> --to-port 8080, it works in that I reach the 8080 server when I connect
> to 80.
>
> But I have to allow 8080 through. Is there a way to provide access to the
> 8080 server via port 80 without having to allow 8080?

Would the following work?

iptables -t mangle -A PREROUTING -p tcp --dport 80 -j MARK
--set-mark 1

iptables -A INPUT -m mark --mark 1 -j ACCEPT
iptables -A INPUT -p tcp --dport 8080 -j DROP

Re: port redirection

[Brian Lewis]

On Sun, 13 Aug 2006 07:18:55 +0100
Graham Murray <graham@gmurray.org.uk> wrote:

> Brian Lewis <bsl04@uark.edu> writes:
> 
> > I run a servlet container that wants to listen on TCP 8080. I want to
> > redirect TCP 80 on my machine to 8080 on the same machine.
> >
> > If I do -t nat -I PREROUTING -i $IF -d $IP -p tcp --dport 80 -j REDIRECT
> > --to-port 8080, it works in that I reach the 8080 server when I connect
> > to 80.
> >
> > But I have to allow 8080 through. Is there a way to provide access to the
> > 8080 server via port 80 without having to allow 8080?
> 
> Would the following work?
> 
> iptables -t mangle -A PREROUTING -p tcp --dport 80 -j MARK
> --set-mark 1
> 
> iptables -A INPUT -m mark --mark 1 -j ACCEPT
> iptables -A INPUT -p tcp --dport 8080 -j DROP

That in conjuction with the REDIRECT rule seems to work well. Thank you.

Port redirection

[Steve Fink]

I am trying to redirect all traffic generated on box $SRC to a
particular UDP port to a different host $SPY. I've done similar things
with whole TCP connections using DNAT and SNAT, but this time I want
UDP and I want to be able to start up the redirection after the
"connection" has been established. (I never see these packets in the
'nat' table.)

The only option that seemed viable, me not knowing much about
networking, was to use the 'mangle' table to set a mark on the
outgoing packets, then use 'ip' to route the packet to $SPY. I've used
iptables a fair amount, but ip not at all.

On $SRC, I ran:
 iptables -t mangle -A OUTPUT -p udp --dport 8765 -j MARK --set-mark 1
 ip rule add fwmark 1 table 50
 ip route add via $SPY table 50
 sysctl net.ipv4.ip_forward=1 # Dunno if this matters
 ip route flush cache

On $SPY, I ran:
 sysctl net.ipv4.ip_forward=1 # Makes sense here

$SRC, $SPY, and $ORIG_DEST (the original destination) can all reach each other.

According to iptables, the mark is getting set on the packets I want
redirected. But tcpdump shows packets still going to the original
destination, not $SPY. I am testing by running this on $SRC

  nc -v -u $ORIG_DEST 8765

And I trigger packets to be sent by hitting enter in that window. The
packets are making it to my dummy server on $ORIG_DEST. They do not
show up to tcpdump on $SPY.

I don't know how to read the output of 'ip route show cache', but it includes

$SPY from $SRC tos lowdelay dev tun0
    cache  mtu 1412 advmss 1372 hoplimit 64
local $SRC from $SPY tos lowdelay dev lo  src $SRC
    cache <local,src-direct>  iif tun0

(I'm testing this over a VPN, hence the tun0 device. Both $ORIG_DEST
and $SPY are accessible via the VPN.)

The only thing I can think of is that $SPY needs to be reachable in a
single hop, but then I'd expect some other error message. On the other
hand, I just tried the above commands on my actual $SRC box, and it
gave me "RTNETLINK answers: Network is unreachable". But as I said,
all three boxes can reach each other via ping and pretty much
anything.

By the way, I don't care if the packets arrive at $SPY with the
destination IP addresses still set to something else; I just want them
to be filterable via another iptables mess. (I'll probably just write
them all out to a file with tcpdump and analyze them after the fact,
but I could imagine writing a application protocol-specific netfilter
module to do the checking that I really want.)

I'd really like for some way to rewrite the destination IP address and
do routing on the resulting packet, but I couldn't figure out how to
do that. Like I said, these packets don't go through the 'nat' table,
and I don't know how to rewrite the destination IP any other way.

Help?

Re: Port redirection

[Pascal Hambourg]

Hello,

Steve Fink a écrit :
> I am trying to redirect all traffic generated on box $SRC to a
> particular UDP port to a different host $SPY. I've done similar things
> with whole TCP connections using DNAT and SNAT, but this time I want
> UDP and I want to be able to start up the redirection after the
> "connection" has been established. (I never see these packets in the
> 'nat' table.)

You don't see these packets in the 'nat' table because the "connection" 
already exists and has an an entry in the conntrack table. You can 
delete a conntrack entry with the conntrack command from the 
conntrack-tools package. You can also prevent the packets to create a 
conntrack entry by using the NOTRACK target in the 'raw' table until 
after you add the NAT rules. Make sure to match packets in both 
directions. After you remove the NOTRACK rules, the next packet will 
enter the 'nat' chains and hit the NAT rules.

> The only option that seemed viable, me not knowing much about
> networking, was to use the 'mangle' table to set a mark on the
> outgoing packets, then use 'ip' to route the packet to $SPY. I've used
> iptables a fair amount, but ip not at all.
> 
> On $SRC, I ran:
>  iptables -t mangle -A OUTPUT -p udp --dport 8765 -j MARK --set-mark 1
>  ip rule add fwmark 1 table 50
>  ip route add via $SPY table 50
>  sysctl net.ipv4.ip_forward=1 # Dunno if this matters

It doesn't matter. Packets are locally generated, the box does not act 
as a router.

>  ip route flush cache
> 
> On $SPY, I ran:
>  sysctl net.ipv4.ip_forward=1 # Makes sense here
> 
> $SRC, $SPY, and $ORIG_DEST (the original destination) can all reach each other.
> 
> According to iptables, the mark is getting set on the packets I want
> redirected. But tcpdump shows packets still going to the original
> destination, not $SPY. I am testing by running this on $SRC
> 
>   nc -v -u $ORIG_DEST 8765
> 
> And I trigger packets to be sent by hitting enter in that window. The
> packets are making it to my dummy server on $ORIG_DEST. They do not
> show up to tcpdump on $SPY.
> 
> I don't know how to read the output of 'ip route show cache', but it includes
> 
> $SPY from $SRC tos lowdelay dev tun0
>     cache  mtu 1412 advmss 1372 hoplimit 64
> local $SRC from $SPY tos lowdelay dev lo  src $SRC
>     cache <local,src-direct>  iif tun0
> 
> (I'm testing this over a VPN, hence the tun0 device. Both $ORIG_DEST
> and $SPY are accessible via the VPN.)

This matters a lot : for both $ORIG_DEST and $SPY, the actual next hop 
is the VPN endpoint.

> The only thing I can think of is that $SPY needs to be reachable in a
> single hop

Indeed, otherwise the actual next hop will forward the packets based on 
the destination address. Whether the packet is marked or not, the next 
hop is the VPN endpoint anyway, and it forwards the packets to 
$ORIG_DEST, not $SPY.

Re: Port redirection

[Steve Fink]

On Wed, Aug 5, 2009 at 7:04 AM, Pascal
Hambourg<pascal.mail@plouf.fr.eu.org> wrote:
>
> You don't see these packets in the 'nat' table because the "connection"
> already exists and has an an entry in the conntrack table. You can delete a
> conntrack entry with the conntrack command from the conntrack-tools package.
> You can also prevent the packets to create a conntrack entry by using the
> NOTRACK target in the 'raw' table until after you add the NAT rules. Make
> sure to match packets in both directions. After you remove the NOTRACK
> rules, the next packet will enter the 'nat' chains and hit the NAT rules.

Thank you! That works perfectly. Both approaches are useful to me (as
is doing NOTRACK and then waiting the 30 seconds for the conntrack
entry to expire; installing conntrack-tools is a bit of a pain on
these boxes.)

I don't need to match packets in both directions, because there aren't
any coming back -- I'm streaming MPEG data out and no response is
desired or necessary.

>>  sysctl net.ipv4.ip_forward=1 # Dunno if this matters
>
> It doesn't matter. Packets are locally generated, the box does not act as a
> router.

Right. That's what I thought, but I tend to cargo-cult that line
because it's usually the thing I forget when I'm bouncing packets
around a network.

>> (I'm testing this over a VPN, hence the tun0 device. Both $ORIG_DEST
>> and $SPY are accessible via the VPN.)
>
> This matters a lot : for both $ORIG_DEST and $SPY, the actual next hop is
> the VPN endpoint.

Ok, that makes sense. 'ip' is only routing, not rewriting.