All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nickola Kolev <nikky@mnet.bg>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] transparent PAT
Date: Wed, 27 Nov 2002 21:29:37 +0000	[thread overview]
Message-ID: <marc-lartc-103843265011827@msgid-missing> (raw)
In-Reply-To: <marc-lartc-103842383732507@msgid-missing>

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

On Wed, 27 Nov 2002 14:40:01 -0600 (CST)
"Martin A. Brown" <mabrown-lartc@securepipe.com> wrote:

> OK!  Now I'm confused.  Why would you need to do DNAT in both directions?

Nope, I do NOT want DNAT. That's just a result of my helpless efforts to
do the thing. :)

> I thought you said you were using ipchains?  If you have iptables, DNAT is 
> really the answer.....you would DNAT anything inbound from machine A to 
> machine B.  Then let the connection tracking take care of the rest.

Yes, correct, I'm using ipchains, and no, I can't use iptables. If I could,
which is not the case, I would probably just redirect the connections to the
other host.

> So, we are agreed....policy based routing probably isn't the answer in 
> this case.

Yes, indeed it seems so, at least to my poor understanding.

>  : Yes, I can, but do I have a way to check that someone is indeed
>  : listening on this port? Except locally, I mean. Beacuse netcat is
>  : binding to the port with no complaints.
> 
> You should be able to use "netstat -ntl" to display the listening sockets
> on your system.

OK, I'll try that.

>  : > If you were using redir, why doesn't the following work:
>  : > # redir --laddr=x.x.x.x --lport=993 --caddr=y.y.y.y --cport=993 --transproxy
>  : No, it yells 
>  : target: connect: Invalid argument
> 
> The poor thing is in pain--that's why it's yelping!  I don't have any 
> problem with the above command line....are you certain that transproxy 
> support was compiled into your redir?

Do I need to enable it explicitly? It didn't seem to me that way, because there's
no switch to turn on any features. Just a plain makefile, in which I couldn't find
any transproxy clues.

And anyway, it starts just fine, but begins to print those error messages when I'm
connecting to the port it's listening on. But this is another scenario - there I'm
redirecting all TCP connections directed to port XXXX anywhere in the world to a local
port, where sits redir.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2002-11-27 21:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-27 19:02 [LARTC] transparent PAT Nickola Kolev
2002-11-27 19:20 ` Martin A. Brown
2002-11-27 20:15 ` Nickola Kolev
2002-11-27 20:40 ` Martin A. Brown
2002-11-27 21:29 ` Nickola Kolev [this message]
2002-11-27 22:39 ` Julian Anastasov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-lartc-103843265011827@msgid-missing \
    --to=nikky@mnet.bg \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.