Ports

Ports

[Mattia Martinello]

Could I allow a packet to transit in the FORWARD chain (under 
masquerading) from some host (or any host) to a host on a port?

iptables -A FORWARD -p tcp -s 0.0.0.0/0 -d 192.168.2.101 -dport 80 -j ACCEPT

don't work (only one -d is allowed). What can I do?

Thank you very much
Bye
Mattia

Re: Ports

[Maciej Soltysiak]

> iptables -A FORWARD -p tcp -s 0.0.0.0/0 -d 192.168.2.101 -dport 80 -j ACCEPT
It is: --dport, not -dport

Regards

Re: Ports

[Ramin Alidousti]

On Mon, Sep 09, 2002 at 07:30:03PM +0200, Mattia Martinello wrote:

> Could I allow a packet to transit in the FORWARD chain (under 
> masquerading) from some host (or any host) to a host on a port?
> 
> iptables -A FORWARD -p tcp -s 0.0.0.0/0 -d 192.168.2.101 -dport 80 -j ACCEPT

I think that your problem is --dport. You missed a "-".

Ramin

> 
> don't work (only one -d is allowed). What can I do?
> 
> Thank you very much
> Bye
> Mattia
> 

Re: Ports

[Mattia Martinello]

Ramin Alidousti ha scritto:

>I think that your problem is --dport. You missed a "-".
>
>Ramin
>
Thank all wery much!
Bye
Mattia

Re: Ports

[Antony Stone]

On Monday 09 September 2002 6:30 pm, Mattia Martinello wrote:

> Could I allow a packet to transit in the FORWARD chain (under
> masquerading) from some host (or any host) to a host on a port?
>
> iptables -A FORWARD -p tcp -s 0.0.0.0/0 -d 192.168.2.101 -dport 80 -j
> ACCEPT
>
> don't work (only one -d is allowed). What can I do?

You can add another '-'   :-)

iptables -A FORWARD -p tcp -d 192.168.2.101 --dport 80 -j ACCEPT

(The -s 0.0.0.0/0 is redundant - remove it to keep thing simpler.)

Antony.

-- 

90% of network problems are routing problems.
9 of the remaining 10% are routing problems in the other direction.
The remaining 1% might be something else, but check the routing anyway.

Re: ports

[maru]

Is there any talk of porting OpenBSD to Xen too?
I mean, Free and NetBSD are ported, and Linux and Plan 9
(and seriously, who uses Plan 9?  yeah, It's got some very cool
features, but was it worth porting?) are ported, so why not
OpenBSD?


~Maru
Also, Xen: very awesome.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Ports

[Mike]

I am trying to port forward ssh portX to portY on same box

I am listening on both ports using tcpdump.

On the same machine, I telnet "localhost portX" or "portY"  results:
NOTHING seen by tcpdump screen .
I do the same in respect to portY.  I also telnet "IP_number portX or
portY  results: NOTHING seen by tcpdump screen.

BTW, on the ssh-server side, I have portX and portY accepting connections.

This is what I have come up with after some google-search.

iptables -t nat -A PREROUTING -p tcp --dport portX -j DNAT --to :portY

No luck,

Re: Ports

[Paul Evans]

[-- Attachment #1: Type: text/plain, Size: 308 bytes --]

On Wed, 19 Nov 2008 23:34:20 -0800
Mike <mikef1007@gmail.com> wrote:

> iptables -t nat -A PREROUTING -p tcp --dport portX -j DNAT --to :portY

You want -j REDIRECT rather than DNAT

-- 
Paul Evans <paul@mxtelecom.com>
Tel: +44 (0) 845 666 7778
Fax: +44 (0) 870 163 4694
http://www.mxtelecom.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Ports

[Mike]

> Mike <mikef1007@gmail.com> wrote:
>
>> iptables -t nat -A PREROUTING -p tcp --dport portX -j DNAT --to :portY
>
> You want -j REDIRECT rather than DNAT

Paul, Thanks for your reply.

I tried the following, prior to that i flushed iptables.

 iptables -t nat -A PREROUTING -p tcp --dport X -j REDIRECT --to-ports Y

I ssh from another box, into the box I issued the above iptable
tcpdump only showed traffic on port X and nothing on port Y

thanks,

Re: Ports

[Paul Evans]

[-- Attachment #1: Type: text/plain, Size: 690 bytes --]

On Thu, 20 Nov 2008 10:00:20 -0800
Mike <mikef1007@gmail.com> wrote:

>  iptables -t nat -A PREROUTING -p tcp --dport X -j REDIRECT
> --to-ports Y
> 
> I ssh from another box, into the box I issued the above iptable
> tcpdump only showed traffic on port X and nothing on port Y

That sounds correct. tcpdump watches very close to the "wire"; that is,
what comes in/goes out over ethernet or PPP or whatever the link uses.
For incoming traffic it will see before nat has rewritten the packets.

Try watching the -i lo interface, instead of eth/ppp/whatever

-- 
Paul Evans <paul@mxtelecom.com>
Tel: +44 (0) 845 666 7778
Fax: +44 (0) 870 163 4694
http://www.mxtelecom.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Ports

[Mike]

On Thu, Nov 20, 2008 at 10:07 AM, Paul Evans <paul@mxtelecom.com> wrote:
> On Thu, 20 Nov 2008 10:00:20 -0800
> Mike <mikef1007@gmail.com> wrote:
>
>>  iptables -t nat -A PREROUTING -p tcp --dport X -j REDIRECT
>> --to-ports Y
>>
>> I ssh from another box, into the box I issued the above iptable
>> tcpdump only showed traffic on port X and nothing on port Y
>
> That sounds correct. tcpdump watches very close to the "wire"; that is,
> what comes in/goes out over ethernet or PPP or whatever the link uses.
> For incoming traffic it will see before nat has rewritten the packets.
>
> Try watching the -i lo interface, instead of eth/ppp/whatever

Tried '-i lo', nothing showed up.

I rechecked my ports, tried again, tcpdump'd X and Y,  ssh'd from
another box and it WORKED!

Thats good and all,  but when I iptables -F , shouldn't I stop seeing
traffic on my redirect port?  Am I missing something else?

thanks,
Mike

Re: Ports

[Paul Evans]

[-- Attachment #1: Type: text/plain, Size: 785 bytes --]

On Thu, 20 Nov 2008 10:24:55 -0800
Mike <mikef1007@gmail.com> wrote:

> Thats good and all,  but when I iptables -F , shouldn't I stop seeing
> traffic on my redirect port?  Am I missing something else?

Not necessarily.

The "nat" table only applies to packets that conntrack believes are
NEW. I.e. TCP SYN packets, or UDP/ICMP for which it doesn't yet have an
entry. As soon as the TCP session is established, nat isn't used any
more and conntrack takes over.

If you keep one existing TCP connection open, that will continue to
have the nat rules applied that were in place when it was established,
regardless of the current ruleset in iptables.

-- 
Paul Evans <paul@mxtelecom.com>
Tel: +44 (0) 845 666 7778
Fax: +44 (0) 870 163 4694
http://www.mxtelecom.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Ports

[Mike]

> The "nat" table only applies to packets that conntrack believes are
> NEW. I.e. TCP SYN packets, or UDP/ICMP for which it doesn't yet have an
> entry. As soon as the TCP session is established, nat isn't used any
> more and conntrack takes over.
>
> If you keep one existing TCP connection open, that will continue to
> have the nat rules applied that were in place when it was established,
> regardless of the current ruleset in iptables.
>

Forgot to include in prev email,  I did  disconnect, then re-initiated
a connection.
Traffic still appeared on my redirect to port.
even sent 'tcp packet' which showed up in my redirect to port.

Re: Ports

[Pascal Hambourg]

Hello,

Mike a écrit :
> I am trying to port forward ssh portX to portY on same box
> 
> iptables -t nat -A PREROUTING -p tcp --dport portX -j DNAT --to :portY

NAT in the PREROUTING chain does not work for the loopback interface. 
Use the OUTPUT chain instead.

Re: Ports

[Pascal Hambourg]

Mike a écrit :
> 
> I rechecked my ports, tried again, tcpdump'd X and Y,  ssh'd from
> another box and it WORKED!

As I said in my previous message, NAT in the PREROUTING chain works only 
for connections from another host, not from the same host.

BTW, REDIRECT may change the destination address too. "DNAT --to :port" 
just changes the destination port.

> Thats good and all,  but when I iptables -F , shouldn't I stop seeing
> traffic on my redirect port?  Am I missing something else?

"iptables -F" flushes only the default table, which is 'filter'. Your 
rule is in the 'nat' table. To flush it, run "iptables -t nat -F".