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 1 of 3  [1] 2 3  Next page →

#4816 — Forwarding a TCP connection

	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?

[toc] | [next] | [standalone]

#4817

On 14/03/2021 21.07, 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?


Certainly.

For example, with an ssh tunnel, run on B:

ssh -L 127.0.0.01:60000:192.168.1.16:80 -N user@A.mylan


A is on 192.168.1.16 in the example.

-- 
Cheers, Carlos.

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

#4818

"Carlos E.R." <robin_listas@es.invalid> writes:

> On 14/03/2021 21.07, 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?

I used to use the iptables DNAT and SNAT targets to achieve this.

> Certainly.
>
> For example, with an ssh tunnel, run on B:
>
> ssh -L 127.0.0.01:60000:192.168.1.16:80 -N user@A.mylan
>
>
> A is on 192.168.1.16 in the example.

With this approach, the server on A will see the wrong source address,
not very transparent.

-- 
https://www.greenend.org.uk/rjk/

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

#4820

On 14/03/2021 23.02, Richard Kettlewell wrote:
> "Carlos E.R." <robin_listas@es.invalid> writes:
>> On 14/03/2021 21.07, 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?
> 
> I used to use the iptables DNAT and SNAT targets to achieve this.
> 
>> Certainly.
>>
>> For example, with an ssh tunnel, run on B:
>>
>> ssh -L 127.0.0.01:60000:192.168.1.16:80 -N user@A.mylan
>>
>>
>> A is on 192.168.1.16 in the example.
> 
> With this approach, the server on A will see the wrong source address,
> not very transparent.

You can change the options as needed. I basically pasted what I use.


      -L [bind_address:]port:host:hostport
      -L [bind_address:]port:remote_socket
      -L local_socket:host:hostport
      -L local_socket:remote_socket
              Specifies that connections to the given TCP port
              or Unix socket on the local (client) host are to
              be forwarded to the given host and port, or Unix
              socket, on the remote side.  This works by allo-
              cating a socket to listen to either a TCP port
              on the local side, optionally bound to the spec-
              ified bind_address, or to a Unix socket.  When-
              ever a connection is made to the local port or
              socket, the connection is forwarded over the
              secure channel, and a connection is made to
              either host port hostport, or the Unix socket
              remote_socket, from the remote machine.

              Port forwardings can also be specified in the
              configuration file.  Only the superuser can for-
              ward privileged ports.  IPv6 addresses can be
              specified by enclosing the address in square
              brackets.

              By default, the local port is bound in accor-
              dance with the GatewayPorts setting.  However,
              an explicit bind_address may be used to bind the
              connection to a specific address.  The
              bind_address of “localhost” indicates that the
              listening port be bound for local use only,
              while an empty address or ‘*’ indicates that the
              port should be available from all interfaces.



-- 
Cheers, Carlos.

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

#4821

"Carlos E.R." <robin_listas@es.invalid> writes:

> On 14/03/2021 23.02, Richard Kettlewell wrote:
>> "Carlos E.R." <robin_listas@es.invalid> writes:
>>> On 14/03/2021 21.07, 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?
>>
>> I used to use the iptables DNAT and SNAT targets to achieve this.
>>
>>> Certainly.
>>>
>>> For example, with an ssh tunnel, run on B:
>>>
>>> ssh -L 127.0.0.01:60000:192.168.1.16:80 -N user@A.mylan
>>>
>>>
>>> A is on 192.168.1.16 in the example.
>>
>> With this approach, the server on A will see the wrong source address,
>> not very transparent.
>
> You can change the options as needed. I basically pasted what I use.

You can’t preserve original source address with SSH forwarding. It’s
simply not possible.

-- 
https://www.greenend.org.uk/rjk/

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

#4826

Le 14/03/2021 à 23:02, Richard Kettlewell a écrit :
> "Carlos E.R." <robin_listas@es.invalid> writes:
> 
>> On 14/03/2021 21.07, 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?

Using the same letter "B" to designate both the host and the port is 
confusing.

>>> That is, my goal is for B to act as man-in-the-middle, totally
>>> transparent as far as B is concerned.

It is not a man-in-the-middle. The clients send connections to system B 
port B, no to system A port P. It would be a man-in-the-middle if 
clients sent connections to system A and the connections were 
intercepted by system B.

> I used to use the iptables DNAT and SNAT targets to achieve this.
> 
>> For example, with an ssh tunnel, run on B:
> 
> With this approach, the server on A will see the wrong source address,

Same with SNAT/MASQUERADE which is required for DNAT to work properly 
within a LAN.

> not very transparent.

Connection forwarding is not transparent anyway.

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

#4819

On 2021-03-14, 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?

Yes lots of ways. You can use the socat program, see

  https://www.cyberciti.biz/faq/linux-unix-tcp-port-forwarding/

netcat (nc) can also do this. So can ssh. You can do it in the firewall 
using iptables.

Have fun.

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

#4822

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.

iptables -t nat -A PREROUTING -p tcp --dport 2222 \
          -j DNAT --to-destination 1.2.3.4:8888

Do you not control the router that's sending the packet to B in the first place?

On my lan, the router forwards packets for some ports to one lan computer, and
packets for some other packets to another one.

Or do you intend to have B do additional things with the packet, such as logging.

Regards, Dave Hodgins

-- 
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

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

#4824

On Sun, 14 Mar 2021 17:40:27 -0400, 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.
> 
> iptables -t nat -A PREROUTING -p tcp --dport 2222 \
>           -j DNAT --to-destination 1.2.3.4:8888

	Tried that - it does not work for me. Check out the set of rules 
that I had to use in the end, as listed in another post to this thread.

> Do you not control the router that's sending the packet to B in the 
first place?

	There is no router involved - this happens between hosts in my 
LAN, behind the router.
 
> On my lan, the router forwards packets for some ports to one lan 
computer, and
> packets for some other packets to another one.
> 
> Or do you intend to have B do additional things with the packet, such 
as logging.

	No. B's job is to forward the connection to A - that's all.

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

#4829

En 33 lignes David W. Hodgins a écrit
dans news:op.0z9k5pu0a3w0dxdave@hodgins.homeip.net
 le dimanche, 14 mars 2021 à 22:40:27 :

>> 	Can this be done?
>
> It's called network address translation.
>
> iptables -t nat -A PREROUTING -p tcp --dport 2222 \
>           -j DNAT --to-destination 1.2.3.4:8888
>
> Do you not control the router that's sending the packet to B in the first place?
>
> On my lan, the router forwards packets for some ports to one lan computer, and
> packets for some other packets to another one.
>
> Or do you intend to have B do additional things with the packet, such as logging.
>
> Regards, Dave Hodgins
>
 It seems to me that somehow A & B are directly connected to each
 other through and eth cable or something, in a LAN all machines go
 through the router and the router can send packets to another machine
 with a set of simple rules, for this, checking out the router, if
 any, might be a good idea.
 
 dyrmak
-- 
¿ Cómo era aquello del rayo verde ?
++++ --- ++++
Linux operating system
++++ --- ++++

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

#4830

On 15.3.21 19.49, dyrmak wrote:
> En 33 lignes David W. Hodgins a écrit
> dans news:op.0z9k5pu0a3w0dxdave@hodgins.homeip.net
>   le dimanche, 14 mars 2021 à 22:40:27 :
> 
>>> 	Can this be done?
>>
>> It's called network address translation.
>>
>> iptables -t nat -A PREROUTING -p tcp --dport 2222 \
>>            -j DNAT --to-destination 1.2.3.4:8888
>>
>> Do you not control the router that's sending the packet to B in the first place?
>>
>> On my lan, the router forwards packets for some ports to one lan computer, and
>> packets for some other packets to another one.
>>
>> Or do you intend to have B do additional things with the packet, such as logging.
>>
>> Regards, Dave Hodgins
>>
>   It seems to me that somehow A & B are directly connected to each
>   other through and eth cable or something, in a LAN all machines go
>   through the router and the router can send packets to another machine
>   with a set of simple rules, for this, checking out the router, if
>   any, might be a good idea.
>   
>   dyrmak


You may be misled here.

In a LAN, the computers may be connected together with a switch
or hub, neither of which is a router. The difference here is if
the network node uses the IP addresses to decide the next-hop
destination.

A hub sends blindly to all ports except the ingress port, and a
switch uses the Ethernet MAC addresses to decide the next-hop target.

-- 

-TV

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

#4833

On 15/03/2021 18.49, dyrmak wrote:
> En 33 lignes David W. Hodgins a écrit
> dans news:op.0z9k5pu0a3w0dxdave@hodgins.homeip.net
>   le dimanche, 14 mars 2021 à 22:40:27 :
> 
>>> 	Can this be done?
>>
>> It's called network address translation.
>>
>> iptables -t nat -A PREROUTING -p tcp --dport 2222 \
>>            -j DNAT --to-destination 1.2.3.4:8888
>>
>> Do you not control the router that's sending the packet to B in the first place?
>>
>> On my lan, the router forwards packets for some ports to one lan computer, and
>> packets for some other packets to another one.
>>
>> Or do you intend to have B do additional things with the packet, such as logging.

>>
>   It seems to me that somehow A & B are directly connected to each
>   other through and eth cable or something, in a LAN all machines go
>   through the router and the router can send packets to another machine
>   with a set of simple rules, for this, checking out the router, if
>   any, might be a good idea.

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.



-- 
Cheers, Carlos.

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

#4834

On Mon, 2021-03-15, Carlos E.R. wrote:
> On 15/03/2021 18.49, dyrmak wrote:
>> En 33 lignes David W. Hodgins a écrit
>> dans news:op.0z9k5pu0a3w0dxdave@hodgins.homeip.net
>>   le dimanche, 14 mars 2021 à 22:40:27 :
>> 
>>>> 	Can this be done?
>>>
>>> It's called network address translation.
>>>
>>> iptables -t nat -A PREROUTING -p tcp --dport 2222 \
>>>            -j DNAT --to-destination 1.2.3.4:8888
>>>
>>> Do you not control the router that's sending the packet to B in the first place?
>>>
>>> On my lan, the router forwards packets for some ports to one lan computer, and
>>> packets for some other packets to another one.
>>>
>>> Or do you intend to have B do additional things with the packet, such as logging.
>
>>>
>>   It seems to me that somehow A & B are directly connected to each
>>   other through and eth cable or something, in a LAN all machines go
>>   through the router and the router can send packets to another machine
>>   with a set of simple rules, for this, checking out the router, if
>>   any, might be a good idea.
>
> 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.

And meanwhile, boxes called "managed switches" seem to be, amongst
other things, routers.  Then if you pay a lot more, they are called
"routers" again. The terminology is terribly confused.

/Jorgen

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

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

#4835

En 40 lignes Jorgen Grahn a écrit
dans news:slrns4vqkn.2ptb.grahn+nntp@frailea.sa.invalid
 le mardi, 16 mars 2021 à 00:15:35 :

> On Mon, 2021-03-15, Carlos E.R. wrote:
>>
>>>>
>>>   It seems to me that somehow A & B are directly connected to each
>>>   other through and eth cable or something, in a LAN all machines go
>>>   through the router and the router can send packets to another machine
>>>   with a set of simple rules, for this, checking out the router, if
>>>   any, might be a good idea.
>>
>> 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.
>
> And meanwhile, boxes called "managed switches" seem to be, amongst
> other things, routers.  Then if you pay a lot more, they are called
> "routers" again. The terminology is terribly confused.
>
> /Jorgen
>

  The only assumption I made here is that in order to get full transparency
  an eventual router might be handy, one router I have can effectively route the LAN
  over the LAN, and yet it can also be configured in switch mode but
  in this case you loose the routing function capacity.
  
  Those boxes are full of layers and those layers activations help them
  impersonate say a hub, a switch, whathever.
  
  Tauno Voipio pointed out however that a LAN can be made out of hubs and switches and
  practically no routers at all.... I overlooked that fact.

 dyrmak
-- 
Dese prisa suba al bote se está yendo la marea
++++ --- ++++
Linux operating system
++++ --- ++++

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

#4836

On 16.3.2021 01:15 AM, Jorgen Grahn wrote:
> On Mon, 2021-03-15, Carlos E.R. wrote:
>> On 15/03/2021 18.49, dyrmak wrote:
>>> En 33 lignes David W. Hodgins a écrit
>>> dans news:op.0z9k5pu0a3w0dxdave@hodgins.homeip.net
>>>    le dimanche, 14 mars 2021 à 22:40:27 :
>>>
>>>>> 	Can this be done?
>>>>
>>>> It's called network address translation.
>>>>
>>>> iptables -t nat -A PREROUTING -p tcp --dport 2222 \
>>>>             -j DNAT --to-destination 1.2.3.4:8888
>>>>
>>>> Do you not control the router that's sending the packet to B in the first place?
>>>>
>>>> On my lan, the router forwards packets for some ports to one lan computer, and
>>>> packets for some other packets to another one.
>>>>
>>>> Or do you intend to have B do additional things with the packet, such as logging.
>>
>>>>
>>>    It seems to me that somehow A & B are directly connected to each
>>>    other through and eth cable or something, in a LAN all machines go
>>>    through the router and the router can send packets to another machine
>>>    with a set of simple rules, for this, checking out the router, if
>>>    any, might be a good idea.
>>
>> 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.
> 
> And meanwhile, boxes called "managed switches" seem to be, amongst
> other things, routers.  Then if you pay a lot more, they are called
> "routers" again. The terminology is terribly confused.
> 
> /Jorgen


A proper managed switch works based on the connectors the traffic
comes in or goes out, and on the Ethernet MAC addresses. The connectors
are called ports in switch parlance, and they must not be confused with
the TCP and UDP ports, which are software-defined mailboxes in protocol.

The managed switches may group ports in groups called VLANs, virtual
LANs. In principle, the ports in different VLANs do not connect to
each other. However, a port may be designated a trunk port carrying
the traffic of several VLANs at the same time. Even there the different
VLANs are kept separate by a special identification tag in the Ethernet
header.

Some operating systems can handle tagged traffic. In Linux, the VLANs
are seen as separate interfaces, marked with a dot and the VLAN number,
e.g. eth0.3 for VLAN id 3 on eth0. The home routers seem to use this
to provide several separate networks for external and internal nets,
using only one Ethernet interface on the processor.

There are bastard cross-overs between managed switches and routers,
peeking into the IP traffic, but otherwise behaving like switches.

A pure switch does not care about the payload protocols riding on
the switched Ethernet.

-- 

-TV

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

#4839

On 2021-03-16, Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote:
>
> A proper managed switch works based on the connectors the traffic
> comes in or goes out, and on the Ethernet MAC addresses. The connectors
> are called ports in switch parlance, and they must not be confused with
> the TCP and UDP ports, which are software-defined mailboxes in protocol.
>
> The managed switches may group ports in groups called VLANs, virtual
> LANs. In principle, the ports in different VLANs do not connect to
> each other. However, a port may be designated a trunk port carrying
> the traffic of several VLANs at the same time. Even there the different
> VLANs are kept separate by a special identification tag in the Ethernet
> header.
>
> Some operating systems can handle tagged traffic. In Linux, the VLANs
> are seen as separate interfaces, marked with a dot and the VLAN number,
> e.g. eth0.3 for VLAN id 3 on eth0. The home routers seem to use this
> to provide several separate networks for external and internal nets,
> using only one Ethernet interface on the processor.
>
> There are bastard cross-overs between managed switches and routers,
> peeking into the IP traffic, but otherwise behaving like switches.
>
> A pure switch does not care about the payload protocols riding on
> the switched Ethernet.

Thank you for the excellent outline. I have been astounded at the 
rubbish being posted on the subject.

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

#4837

On 16/03/2021 00.15, Jorgen Grahn wrote:
> On Mon, 2021-03-15, Carlos E.R. wrote:
>> On 15/03/2021 18.49, dyrmak wrote:
>>> En 33 lignes David W. Hodgins a écrit
>>> dans news:op.0z9k5pu0a3w0dxdave@hodgins.homeip.net
>>>    le dimanche, 14 mars 2021 à 22:40:27 :
>>>
>>>>> 	Can this be done?
>>>>
>>>> It's called network address translation.
>>>>
>>>> iptables -t nat -A PREROUTING -p tcp --dport 2222 \
>>>>             -j DNAT --to-destination 1.2.3.4:8888
>>>>
>>>> Do you not control the router that's sending the packet to B in the first place?
>>>>
>>>> On my lan, the router forwards packets for some ports to one lan computer, and
>>>> packets for some other packets to another one.
>>>>
>>>> Or do you intend to have B do additional things with the packet, such as logging.
>>
>>>>
>>>    It seems to me that somehow A & B are directly connected to each
>>>    other through and eth cable or something, in a LAN all machines go
>>>    through the router and the router can send packets to another machine
>>>    with a set of simple rules, for this, checking out the router, if
>>>    any, might be a good idea.
>>
>> 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.
> 
> And meanwhile, boxes called "managed switches" seem to be, amongst
> other things, routers.  Then if you pay a lot more, they are called
> "routers" again. The terminology is terribly confused.

Right :-)

Oh, and I forgot that the routing table of the computers in the LAN may 
be configured so that the send LAN traffic to the gateway (so that it 
does traverse the actual router). It is an error, of course, as it slows 
traffic, but I have seen it.


-- 
Cheers, Carlos.

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

#4838

>> 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.
>
> And meanwhile, boxes called "managed switches" seem to be, amongst
> other things, routers.  

No they are not. A router, in Internet parlance, transfers IP packets 
from one IP subnetwork to another.

A switch switches ethernet frames between its ethernet ports.

> Then if you pay a lot more, they are called
> "routers" again. The terminology is terribly confused.

No it not. Sorry, but there is just a lot of aconfusion among people who 
don't understand.

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

#4880

On 3/16/21 7:49 AM, Jim Jackson 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.
>>
>> And meanwhile, boxes called "managed switches" seem to be, amongst
>> other things, routers.
> 
> No they are not. A router, in Internet parlance, transfers IP packets
> from one IP subnetwork to another.
> 

I think what he's trying to say, and what is quite accurate, are that 
many "managed switches" have routing functions in them.


I've got a Mikrotik Cloud Core Switch and it absolutely does have the 
ability to route.

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

#4883

On 5/28/21 2:19 PM, Johann Beretta wrote:
> I think what he's trying to say, and what is quite accurate, are that 
> many "managed switches" have routing functions in them.

It *REALLY* depends if it's a Layer 2 or a Layer 3 switch.

Layer 2 switches can be managed, as in configure VLAN and other L2 
options.  Verses a dumb L2 switch that can't have any of those 
configurations.

Layer 3 switches are managed and function as routers, maybe firewalls, 
and maybe (L3) NAT.  These L3 features (effectively) /require/ some form 
of management to configure.

I tend to see one-third, one-third, one-third split between L2 
unmanaged, L2 manged, and L3 managed switches.  L2 switches are twice as 
likely to be used than L3 switches, especially at higher port density, 
because of price.  Likewise with unmanaged vs managed L2 switches.

Smaller port densities often found in the SOHO market tend to be modem / 
router combination devices that frequently also happen to have an L2 
chip that provides up to 8 ports.  These ports may or may not be managed.

> I've got a Mikrotik Cloud Core Switch and it absolutely does have the 
> ability to route.

IMHO, Mikrotik is on the upper end of their product market and fits 
completely inside the L3 managed switch segment.

7 of the 16 results on the first page of an Amazon search for "24 port 
ethernet switch" were managed.  The remaining 9 were unmanaged.



-- 
Grant. . . .
unix || die

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web