Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #4816 > unrolled thread

Forwarding a TCP connection

Back to article view | Back to comp.os.linux.networking

Contents

  Forwarding a TCP connection John Smith <12345@whatismyemailaddress.xyz> - 2021-03-14 20:07 +0000
    Re: Forwarding a TCP connection "Carlos E.R." <robin_listas@es.invalid> - 2021-03-14 22:41 +0100
      Re: Forwarding a TCP connection Richard Kettlewell <invalid@invalid.invalid> - 2021-03-14 22:02 +0000
        Re: Forwarding a TCP connection "Carlos E.R." <robin_listas@es.invalid> - 2021-03-14 23:26 +0100
          Re: Forwarding a TCP connection Richard Kettlewell <invalid@invalid.invalid> - 2021-03-14 22:46 +0000
        Re: Forwarding a TCP connection Pascal Hambourg <pascal@plouf.fr.eu.org> - 2021-03-15 09:42 +0100
    Re: Forwarding a TCP connection Jim Jackson <jj@franjam.org.uk> - 2021-03-14 22:03 +0000
    Re: Forwarding a TCP connection "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2021-03-14 17:40 -0400
      Re: Forwarding a TCP connection John Smith <12345@whatismyemailaddress.xyz> - 2021-03-14 23:23 +0000
      Re: Forwarding a TCP connection dyrmak <dyrmak@quelite.terre.invalid> - 2021-03-15 17:49 +0000
        Re: Forwarding a TCP connection Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-03-15 20:14 +0200
        Re: Forwarding a TCP connection "Carlos E.R." <robin_listas@es.invalid> - 2021-03-15 23:28 +0100
          Re: Forwarding a TCP connection Jorgen Grahn <grahn+nntp@snipabacken.se> - 2021-03-15 23:15 +0000
            Re: Forwarding a TCP connection dyrmak <dyrmak@orange.fr.invalid> - 2021-03-16 07:59 +0000
            Re: Forwarding a TCP connection Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-03-16 11:16 +0200
              Re: Forwarding a TCP connection Jim Jackson <jj@franjam.org.uk> - 2021-03-16 14:53 +0000
            Re: Forwarding a TCP connection "Carlos E.R." <robin_listas@es.invalid> - 2021-03-16 03:21 +0100
            Re: Forwarding a TCP connection Jim Jackson <jj@franjam.org.uk> - 2021-03-16 14:49 +0000
              Re: Forwarding a TCP connection Johann Beretta <beretta@nun-ya-bizness.com> - 2021-05-28 13:19 -0700
                Re: Forwarding a TCP connection Grant Taylor <gtaylor@tnetconsulting.net> - 2021-05-28 16:20 -0600
          Re: Forwarding a TCP connection Johann Beretta <beretta@nun-ya-bizness.com> - 2021-05-28 13:15 -0700
            Re: Forwarding a TCP connection Grant Taylor <gtaylor@tnetconsulting.net> - 2021-05-28 16:23 -0600
              Re: Forwarding a TCP connection Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-05-29 18:42 +0200
                Re: Forwarding a TCP connection Grant Taylor <gtaylor@tnetconsulting.net> - 2021-05-29 19:29 -0600
                  Re: Forwarding a TCP connection Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-05-30 12:08 +0200
                    Re: Forwarding a TCP connection Grant Taylor <gtaylor@tnetconsulting.net> - 2021-05-31 22:43 -0600
                      Re: Forwarding a TCP connection Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-06-01 08:51 +0200
      Re: Forwarding a TCP connection Johann Beretta <beretta@nun-ya-bizness.com> - 2021-03-24 19:30 -0700
        Re: Forwarding a TCP connection Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-03-25 16:35 +0200
          Re: Forwarding a TCP connection Pascal Hambourg <pascal@plouf.fr.eu.org> - 2021-03-25 20:03 +0100
            Re: Forwarding a TCP connection Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-03-25 21:34 +0200
              Re: Forwarding a TCP connection Pascal Hambourg <pascal@plouf.fr.eu.org> - 2021-03-25 21:54 +0100
              Re: Forwarding a TCP connection Johann Beretta <beretta@nun-ya-bizness.com> - 2021-03-29 13:45 -0700
          Re: Forwarding a TCP connection Johann Beretta <beretta@nun-ya-bizness.com> - 2021-03-29 13:43 -0700
            Re: Forwarding a TCP connection Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-03-30 20:26 +0300
              Re: Forwarding a TCP connection Johann Beretta <beretta@nun-ya-bizness.com> - 2021-03-30 22:49 -0700
                Re: Forwarding a TCP connection Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-03-31 16:29 +0000
    Re: Forwarding a TCP connection John Smith <12345@whatismyemailaddress.xyz> - 2021-03-14 23:13 +0000
      Re: Forwarding a TCP connection Jorgen Grahn <grahn+nntp@snipabacken.se> - 2021-03-15 06:59 +0000
      Re: Forwarding a TCP connection Pascal Hambourg <pascal@plouf.fr.eu.org> - 2021-03-15 09:48 +0100
        Re: Forwarding a TCP connection John Smith <12345@whatismyemailaddress.xyz> - 2021-03-15 13:44 +0000
          Re: Forwarding a TCP connection Pascal Hambourg <pascal@plouf.fr.eu.org> - 2021-03-15 20:49 +0100
            Re: Forwarding a TCP connection John Smith <12345@whatismyemailaddress.xyz> - 2021-03-15 21:10 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#4881

On 3/15/21 3:28 PM, Carlos E.R. wrote:

> 
> Home routers are not actually "routing" the LAN. The LAN is connected to 
> a switch in the "router" box. The router part of the "router" does not 
> intervene in that traffic.
> 

Neither do enterprise routers.  As far as I know, every modern 
non-internet-only router connects local traffic to a switch.

You CAN make a particular port "routable" on higher-end routers, but 
it's rarely mandatory.

[toc] | [prev] | [next] | [standalone]

#4884

On 5/28/21 2:15 PM, Johann Beretta wrote:
> Neither do enterprise routers.  As far as I know, every modern 
> non-internet-only router connects local traffic to a switch.

It depends on what the router is and how it's built.

It's possible to combine ports on some routers into a logical switch, 
which will use software to switch the traffic between the ports.

This is very much akin to bridging under Linux.  Add two or more ports 
to a bridge and use kernel software to do switching.



-- 
Grant. . . .
unix || die

[toc] | [prev] | [next] | [standalone]

#4895

Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>On 5/28/21 2:15 PM, Johann Beretta wrote:
>> Neither do enterprise routers.  As far as I know, every modern 
>> non-internet-only router connects local traffic to a switch.
>
>It depends on what the router is and how it's built.
>
>It's possible to combine ports on some routers into a logical switch, 
>which will use software to switch the traffic between the ports.
>
>This is very much akin to bridging under Linux.  Add two or more ports 
>to a bridge and use kernel software to do switching.

The Bridge - Switch - Router terminology has been fully usurped by
marketdroids in the last two decades. All one can say at the moment,
if it's called router, it probably has not enough ports, and if it's
called l3-switch, it's actually a router with a lot of ports that can
route packets really fast.

A router proper with no switching capability would not be able to have
multiple ports in a single network segment / VLAN.

Greetings
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]

#4905

On 5/29/21 10:42 AM, Marc Haber wrote:
> The Bridge - Switch - Router terminology has been fully usurped by 
> marketdroids in the last two decades.

Only if we don't call them to the mat and use the proper terms ourselves.

> All one can say at the moment, if it's called router, it probably 
> has not enough ports, and if it's called l3-switch, it's actually a 
> router with a lot of ports that can route packets really fast.

I've used many big iron routers that are a LOT faster than even 10 / 25 
/ 40 / 50 Gbps L3 switches.  Big iron routers really start to shine when 
you need to do more than simple L3 routing between simple Ethernet 
segments.  When you want to do more advanced things and / or have a full 
routing table* is when you actually /need/ a big iron router.

Current Default Free Zone feed that I've got shows 831,432 prefixes. 
Many, if not most L3 switches fall over at that scale.

> A router proper with no switching capability would not be able to 
> have multiple ports in a single network segment / VLAN.

Sure it can.  Cisco calls this a "Bridge Virtual Interface" or a "Switch 
Virtual Interface" (depending on the router in question).  It uses 
software and the CPU to join multiple nominally independent interfaces 
into a broadcast domain.



-- 
Grant. . . .
unix || die

[toc] | [prev] | [next] | [standalone]

#4913

Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>On 5/29/21 10:42 AM, Marc Haber wrote:
>> A router proper with no switching capability would not be able to 
>> have multiple ports in a single network segment / VLAN.
>
>Sure it can.  Cisco calls this a "Bridge Virtual Interface" or a "Switch 
>Virtual Interface" (depending on the router in question).  It uses 
>software and the CPU to join multiple nominally independent interfaces 
>into a broadcast domain.

That is a router with added switching capability.

Thanks for proving my point and for unnecessarily taking this
conversation into a market segment that probably 1 % of people
(including the two of us) will ever see.

-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]

#4922

On 5/30/21 4:08 AM, Marc Haber wrote:
> That is a router with added switching capability.

What is "switching capability"?  Is it hardware as in a switch on a chip 
that many SOHO routers have?  Or is it some sort of higher end ASIC that 
gets into the data path?  Or is it software a la bridging on Linux?

> Thanks for proving my point and for unnecessarily taking this
> conversation into a market segment that probably 1 % of people
> (including the two of us) will ever see.

I know a number of people that use BVI / SVI on routers.  It's quite 
common to logically join a wired and wireless segment and route between 
said logical segment and other physical segments.



-- 
Grant. . . .
unix || die

[toc] | [prev] | [next] | [standalone]

#4925

Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>On 5/30/21 4:08 AM, Marc Haber wrote:
>> That is a router with added switching capability.
>
>What is "switching capability"?  Is it hardware as in a switch on a chip 
>that many SOHO routers have?  Or is it some sort of higher end ASIC that 
>gets into the data path?  Or is it software a la bridging on Linux?

All three apply. _You_ know that.

Greetings
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]

#4840

[Multipart message — attachments visible in raw view] — view raw

On 3/14/21 2:40 PM, David W. Hodgins wrote:
> On Sun, 14 Mar 2021 16:07:04 -0400, John Smith
> <12345@whatismyemailaddress.xyz> wrote:
> 
>>     I have a Linux system A in my network where a TCP server is
>> running at port P. The details of this server are irrelevant beyond the
>> fact that it is a TCP server.
>>
>>     What I would like to do is the following;
>>
>>     I have another Linux system B in the same network. Would it be
>> possible to configure B so that when be receives a TCP connection request
>> on port B, the connection is silently and transparently forwarded to A?
>> That is, my goal is for B to act as man-in-the-middle, totally
>> transparent as far as B is concerned.
>>
>>     Can this be done?
> 
> It's called network address translation.

Actually, that's PORT FORWARDING.

[toc] | [prev] | [next] | [standalone]

#4841

On 25.3.21 4.30, Johann Beretta wrote:
> On 3/14/21 2:40 PM, David W. Hodgins wrote:
>> On Sun, 14 Mar 2021 16:07:04 -0400, John Smith
>> <12345@whatismyemailaddress.xyz> wrote:
>>
>>>      I have a Linux system A in my network where a TCP server is
>>> running at port P. The details of this server are irrelevant beyond the
>>> fact that it is a TCP server.
>>>
>>>      What I would like to do is the following;
>>>
>>>      I have another Linux system B in the same network. Would it be
>>> possible to configure B so that when be receives a TCP connection request
>>> on port B, the connection is silently and transparently forwarded to A?
>>> That is, my goal is for B to act as man-in-the-middle, totally
>>> transparent as far as B is concerned.
>>>
>>>      Can this be done?
>>
>> It's called network address translation.
> 
> Actually, that's PORT FORWARDING.


Port forwarding is just a kind of NAT.

-- 

-TV

[toc] | [prev] | [next] | [standalone]

#4842

Le 25/03/2021 à 15:35, Tauno Voipio a écrit :
> 
> Port forwarding is just a kind of NAT.

Not always. As already mentioned in this thread, it may also be a kind 
of proxy/relay performed by programs such as socat or ssh.

[toc] | [prev] | [next] | [standalone]

#4843

On 25.3.21 21.03, Pascal Hambourg wrote:
> Le 25/03/2021 à 15:35, Tauno Voipio a écrit :
>>
>> Port forwarding is just a kind of NAT.
> 
> Not always. As already mentioned in this thread, it may also be a kind 
> of proxy/relay performed by programs such as socat or ssh.


In my vocabulary, proxies are special servers which
are endpoints of the original connections.

SSH forwarding is actaully a kind of VPN tunnel.

-- 

-TV

[toc] | [prev] | [next] | [standalone]

#4844

Le 25/03/2021 à 20:34, Tauno Voipio a écrit :
> On 25.3.21 21.03, Pascal Hambourg wrote:
>> Le 25/03/2021 à 15:35, Tauno Voipio a écrit :
>>>
>>> Port forwarding is just a kind of NAT.
>>
>> Not always. As already mentioned in this thread, it may also be a kind 
>> of proxy/relay performed by programs such as socat or ssh.
> 
> In my vocabulary, proxies are special servers which
> are endpoints of the original connections.

Anyone would agree with you. So what ?
Do you mean it does not qualify as port forwarding ?

> SSH forwarding is actaully a kind of VPN tunnel.

Again, so what ?

In all these cases, data sent to an address:port are transparently 
forwarded to another address:port.

[toc] | [prev] | [next] | [standalone]

#4860

[Multipart message — attachments visible in raw view] — view raw

On 3/25/21 12:34 PM, Tauno Voipio wrote:

> 
> 
> In my vocabulary, proxies are special servers which
> are endpoints of the original connections.
> 

Who cares? We use industry language here.  I don't care if you want to
start calling Proxies the 3-fisted-dance in "your language".

Quit being an asshat. You're using the wrong terms.  Just update the
knowledge in your brain and move on.  The more you defend your stance,
when you are wrong, the more you look like an asshole.

[toc] | [prev] | [next] | [standalone]

#4859

[Multipart message — attachments visible in raw view] — view raw

On 3/25/21 7:35 AM, Tauno Voipio wrote:
> On 25.3.21 4.30, Johann Beretta wrote:
>> On 3/14/21 2:40 PM, David W. Hodgins wrote:
>>> On Sun, 14 Mar 2021 16:07:04 -0400, John Smith
>>> <12345@whatismyemailaddress.xyz> wrote:
>>>
>>>>      I have a Linux system A in my network where a TCP server is
>>>> running at port P. The details of this server are irrelevant beyond the
>>>> fact that it is a TCP server.
>>>>
>>>>      What I would like to do is the following;
>>>>
>>>>      I have another Linux system B in the same network. Would it be
>>>> possible to configure B so that when be receives a TCP connection
>>>> request
>>>> on port B, the connection is silently and transparently forwarded to A?
>>>> That is, my goal is for B to act as man-in-the-middle, totally
>>>> transparent as far as B is concerned.
>>>>
>>>>      Can this be done?
>>>
>>> It's called network address translation.
>>
>> Actually, that's PORT FORWARDING.
>
>
> Port forwarding is just a kind of NAT.
>
No it's not. There's no translation done. The connection is forwarded to
the same device always, if the connection comes in on a specific port.

NAT will forward a connection on a given port to whatever computer is
associated with that particular TCP connection at a given time.

Maybe you could argue that PORT FORWARDING is a subset or related to
NAT, but when we talk about these things in the industry we use specific
terms for a reason.

[toc] | [prev] | [next] | [standalone]

#4861

On 29.3.21 23.43, Johann Beretta wrote:
> On 3/25/21 7:35 AM, Tauno Voipio wrote:
>> On 25.3.21 4.30, Johann Beretta wrote:
>>> On 3/14/21 2:40 PM, David W. Hodgins wrote:
>>>> On Sun, 14 Mar 2021 16:07:04 -0400, John Smith
>>>> <12345@whatismyemailaddress.xyz> wrote:
>>>>
>>>>>       I have a Linux system A in my network where a TCP server is
>>>>> running at port P. The details of this server are irrelevant beyond the
>>>>> fact that it is a TCP server.
>>>>>
>>>>>       What I would like to do is the following;
>>>>>
>>>>>       I have another Linux system B in the same network. Would it be
>>>>> possible to configure B so that when be receives a TCP connection
>>>>> request
>>>>> on port B, the connection is silently and transparently forwarded to A?
>>>>> That is, my goal is for B to act as man-in-the-middle, totally
>>>>> transparent as far as B is concerned.
>>>>>
>>>>>       Can this be done?
>>>>
>>>> It's called network address translation.
>>>
>>> Actually, that's PORT FORWARDING.
>>
>>
>> Port forwarding is just a kind of NAT.
>>
> No it's not. There's no translation done. The connection is forwarded to
> the same device always, if the connection comes in on a specific port.
> 
> NAT will forward a connection on a given port to whatever computer is
> associated with that particular TCP connection at a given time.
> 
> Maybe you could argue that PORT FORWARDING is a subset or related to
> NAT, but when we talk about these things in the industry we use specific
> terms for a reason.


Are you telling that the destination IP of a forwarded
IP packet is not changed?

-- 

-TV

[toc] | [prev] | [next] | [standalone]

#4863

[Multipart message — attachments visible in raw view] — view raw

On 3/30/21 10:26 AM, Tauno Voipio wrote:

>> terms for a reason.
> 
> 
> Are you telling that the destination IP of a forwarded
> IP packet is not changed?
> 

No.  But keep at it. Keep insisting that Port Forwarding and NAT are the
same thing...

We have two definitions for two reasons. One is for one thing and the
other is for another thing.

They may be related but they are different.

[toc] | [prev] | [next] | [standalone]

#4864

On 2021-03-31, Johann Beretta <beretta@nun-ya-bizness.com> wrote:

> On 3/30/21 10:26 AM, Tauno Voipio wrote:
>
>>> terms for a reason.
>>
>> Are you telling that the destination IP of a forwarded
>> IP packet is not changed?
>
> No.  But keep at it. Keep insisting that Port Forwarding and NAT are the
> same thing...
>
> We have two definitions for two reasons. One is for one thing and the
> other is for another thing.
>
> They may be related but they are different.

    "When I use a word," Humpty Dumpty said in rather a
    scornful tone, "it means just what I choose it to mean -
    neither more nor less."

    "The question is," said Alice, "whether you can make
    words mean so many different things."

    "The question is," said Humpty Dumpty, "which is to
    be master - that's all."

      -- Lewis Carroll: Through the Looking Glass

-- 
/~\  Charlie Gibbs                  |  They don't understand Microsoft
\ /  <cgibbs@kltpzyxm.invalid>      |  has stolen their car and parked
 X   I'm really at ac.dekanfrus     |  a taxi in their driveway.
/ \  if you read it the right way.  |    -- Mayayana

[toc] | [prev] | [next] | [standalone]

#4823

On Sun, 14 Mar 2021 20:07:04 +0000, John Smith wrote:

> I have a Linux system A in my network where a TCP server is running at
> port P. The details of this server are irrelevant beyond the fact that
> it is a TCP server.
> 
> 	What I would like to do is the following;
> 
> 	I have another Linux system B in the same network. Would it be
> possible to configure B so that when be receives a TCP connection
> request on port B, the connection is silently and transparently
> forwarded to A? That is, my goal is for B to act as man-in-the-middle,
> totally transparent as far as B is concerned.
> 
> 	Can this be done?

	Actually, I found out how to do it with iptables. Assuming that 
the internal network is the 192.168.0 network, one can create the following 
IP tables rules in B:

   iptables -t nat -A PREROUTING -i <nic> -p tcp --dport <port> -j DNAT --to-destination <A-ip-address>:<port>
   iptables -A FORWARD -i <nic> -d <A-ip-address> -p tcp --dport <port> -j ACCEPT
   iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d <A-ip-address> -p tcp --dport <port> -j SNAT --to-source <B-ip-address>
   iptables -t nat -A POSTROUTING -o <nic> -d <A-ip-address> -p tcp --dport <port> -j SNAT --to-source <B-ip-address>

where

   <nic>: The appropriate network interface in B.
   <port>: The port number.
   <A-ip-address>: The IP address of A.
   <B-ip-address>: The IP address of B.

After doing this, when some other system in my network attempts to contact B 
at port P, the connection gets transparently forwarded to A at port P.

	This does look quite complicated for what it does. The thing is, I 
tried with simpler suggestions that I came across online, and couldn't get 
them to work. If anybody has a simpler set of rules that works, I'd be happy 
to learn about it.

[toc] | [prev] | [next] | [standalone]

#4825

On Sun, 2021-03-14, John Smith wrote:
> On Sun, 14 Mar 2021 20:07:04 +0000, John Smith wrote:
>
>> I have a Linux system A in my network where a TCP server is running at
>> port P. The details of this server are irrelevant beyond the fact that
>> it is a TCP server.
>> 
>> 	What I would like to do is the following;
>> 
>> 	I have another Linux system B in the same network. Would it be
>> possible to configure B so that when be receives a TCP connection
>> request on port B, the connection is silently and transparently
>> forwarded to A? That is, my goal is for B to act as man-in-the-middle,
>> totally transparent as far as B is concerned.
>> 
>> 	Can this be done?
>
> 	Actually, I found out how to do it with iptables. Assuming that 
> the internal network is the 192.168.0 network, one can create the following 
> IP tables rules in B:
>
>    iptables -t nat -A PREROUTING -i <nic> -p tcp --dport <port> -j DNAT --to-destination <A-ip-address>:<port>
>    iptables -A FORWARD -i <nic> -d <A-ip-address> -p tcp --dport <port> -j ACCEPT
>    iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d <A-ip-address> -p tcp --dport <port> -j SNAT --to-source <B-ip-address>
>    iptables -t nat -A POSTROUTING -o <nic> -d <A-ip-address> -p tcp --dport <port> -j SNAT --to-source <B-ip-address>
>
> where
>
>    <nic>: The appropriate network interface in B.
>    <port>: The port number.
>    <A-ip-address>: The IP address of A.
>    <B-ip-address>: The IP address of B.

See if you can provide host names instead of IPv4 addresses.  You can
for -s and -d; for --to-destination it's not documented but that
documentation seems a bit off in other ways.

> After doing this, when some other system in my network attempts to contact B 
> at port P, the connection gets transparently forwarded to A at port P.
>
> 	This does look quite complicated for what it does. The thing is, I 
> tried with simpler suggestions that I came across online, and couldn't get 
> them to work. If anybody has a simpler set of rules that works, I'd be happy 
> to learn about it.

I don't know, but I'm not surprised if it ends up as four rules.

One problem with the iptables approach is that it circumvents the IP
stack on B. Port B:B becomes special.  A process on B which binds to
port B will succeed, but will not see any traffic.  If B is in the
dynamic range, TCP clients will have problems at random every 10,000
time you run it, or something.

Might be worth googling for solutions to that.  One crude way is to
have a dummy process bind to the port, e.g. a 'nc -l -k'.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#4827

Le 15/03/2021 à 00:13, John Smith a écrit :
> 
> 	Actually, I found out how to do it with iptables. Assuming that
> the internal network is the 192.168.0 network, one can create the following
> IP tables rules in B:
> 
>     iptables -t nat -A PREROUTING -i <nic> -p tcp --dport <port> -j DNAT --to-destination <A-ip-address>:<port>
>     iptables -A FORWARD -i <nic> -d <A-ip-address> -p tcp --dport <port> -j ACCEPT

This rule is useless if the FORWARD chain ACCEPTs all traffic by default.

>     iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d <A-ip-address> -p tcp --dport <port> -j SNAT --to-source <B-ip-address>
>     iptables -t nat -A POSTROUTING -o <nic> -d <A-ip-address> -p tcp --dport <port> -j SNAT --to-source <B-ip-address>

These two rules are redundant with each other.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.os.linux.networking

csiph-web