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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"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/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"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/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 .

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 15 Mar 2021 09:48:26 +0100, Pascal Hambourg wrote:

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.

Well, this works, which is what matters to me. I am of course
open to simplifications. Please suggest some.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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
++++ --- ++++

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 15/03/2021 à 14:44, John Smith a écrit :

On Mon, 15 Mar 2021 09:48:26 +0100, Pascal Hambourg wrote:

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.

Well, this works, which is what matters to me. I am of course
open to simplifications. Please suggest some.

I thought it was obvious.
Remove the FORWARD rule if ACCEPT is the default.
Remove either POSTROUTING rule.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 15 Mar 2021 20:49:44 +0100, Pascal Hambourg wrote:

Le 15/03/2021 à 14:44, John Smith a écrit :

On Mon, 15 Mar 2021 09:48:26 +0100, Pascal Hambourg wrote:

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.

Well, this works, which is what matters to me. I am of course
open to simplifications. Please suggest some.

I thought it was obvious.
Remove the FORWARD rule if ACCEPT is the default.
Remove either POSTROUTING rule.

Yes, after removing the second and third rules it still works as expected. Much appreciated.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 .

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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
++++ --- ++++

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is a multi-part message in MIME format.
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.



-----BEGIN PGP PUBLIC KEY BLOCK-----

mQGNBF64/IEBDACVrdj4Yfr7PC/t7tBofnMWWDoWiRxl+Oo64YjsamZGiy0hJHfP ZhI/pnOgqhy6pzsF/8c9Dx9A9SSAJOvC96wMTHgdh4GbffekCwoIXcKZeg9bjXjV Nth5CYOSBTQ9C/pl/j0CwjBQ9mdyK7FoHMlBEmQ4ButtBJgPNjyruiFkBt2r/99u w+hZEt+tO3D69v2MBMVF8pjZWzDDoIsbCUQGtaDD4uAIMqdDl28yw5FeYFg7PKLJ DXft8pNm/4bWv7BizTEVwSkcpPMR/6v/gXUhUsqCoqaWT9oSALmO5l9JfuNk2mpP bjue5joPlpOzaH+ZC0et/eynzyTxOpIAL97g1SVQLqqKRMu3atFda53ZyMNAcH3G R1gV5kX1rM3Ajyw1d7hp1rAYINdB/O/Y8VkNn0j6NZmEi8E1AwK3hu4ZJPIr9FQF bsWmAtjIgO1VXHxvxB7nYF5o7M350hW9SZlkbDf9NWBUHJlc5j4WVEYCjw1C3y8h OwFl1RfDFETqmdUAEQEAAbQrSm9oYW5uIEJlcmV0dGEgPGJlcmV0dGFAbnVuLXlh LWJpem5lc3MuY29tPokB1AQTAQgAPhYhBJx2orrQOL31I0cnEBM/4/Zk8Q8TBQJe uP0PAhsDBQkB4TOABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEBM/4/Zk8Q8T 0KYL/jL1DoQWCMil5EPlLSDG3iByV711VChSpWGbE4m2KrMjMdG0gQBNpg3IChKi tP5/5YdxHGKGjuDxvF/laTq/5KXosNmfdaJr9pmztOWT7tvmlwM+zUR782EQJeeU rGfv6TwYng7TUEaBH86Rg8m6fMKNqSt9MLly+p48Lv8TNj1RofvMv5Ng5xJWkGJ2 +yJ6k61h6Xg8OFY/AEs98OMejDKPq2PTZyH1BQKmyDk82wOGUdSkQoA41aZSckki aXFXIG97NhXY+dcZbOVCjXez0Iujo4vSCbM+x63fX7FyyNsG4f2vPfqhrqNGgrwD KQxYzWgVfvCqKpW6S75l0DfelMFAjM5GcpKs65vRyjRDuMlj6/jSN0O6Os8EOlhr lHBoY1PrBwTX+pBgb1esF2KLbFjfxGLzvbfR85TbYaZi/hohwD/rm+s5QWe03pO/ n85mdVxYAhAhvXsO6s7wfTm0qc/SK7Xp82aYOKVArarNgRIMul7UBo2786ZFhmZY wQGPQ7kBjQReuPzOAQwAoWku3K9ipwwiuH/9C8uUqY1kZy9VW/K7b5uXKww43Dl5 SAFTd+TC8nySqSacHohTQSnd8r3eZgX6az3SR30Y0F6Ftprbx0dkRABKtVzEcxCJ Y2+lqfT6aPIQh+tp/mmWVzrmeYlQNFVLNbu0Tk62K0sedfnhDGgqN4DEWQqgGfG5 Zsj1VcYoXYkt1V/U16GPs75aqWdt+OQmlDb2FQbo/HcsB1bdrE9A7fM39WQpod/k tkAZRJM6RX1f2hJAFwgBEKYieK4ZGfMtgxpIMnvBDwB1FuLw2sGshRtaPO8t0F+w jR/i6PEwCWZSaENhik+oAxDgaKPkxZHpzYS3RM67HoRie1ewuqAw77xeAI4WLbxo +FNg8W+kdPgdRkGeMaYot4hoVGpgF0q0cBPm97wAysxbAu/TDlX/ev4XEkRnZg7k ScCVTrkk9bSVIXs0uB8qkudcudrzokZJ+6v+X5JKgwOMBBSY7sk11T3azog6wxJN BuqS1wB/H4Kht9OMLoTVABEBAAGJAbwEGAEIACYWIQScdqK60Di99SNHJxATP+P2 ZPEPEwUCXrj8zgIbDAUJAeEzgAAKCRATP+P2ZPEPE1UNC/sFAMZnLH8OdDwflfhr iyESWHhRJb1xC4tlJzZ/ufbWY8SbVqO5HbA7EALwW3Ony8SNRRN/OUBw7bM12VPX 0ya6RTQHtPzweL98AnGu0YbyHtKwJrNlGQS0LKWDv4FWQ6f8HxZQt0EzhgRaudGE MHNACuKbxWFpvNAM95LNpLDjRE+DJYGnsDOCRRC4fFRTG0+vqIqgniQzHmn8ddr6 5NazPg07TJzqLjsNBcTCGvRivoRDRP75PnQS8VppnyWubbXJjffmuIG2iqHnY5as ibsSo+TJ+7UEhbNx+uQBKO5KXvG/u9eWgyJz/Uf47zUbG9v9vocbOSbylPHjC3uO ONw91nUHLmGzi3ZmeyPeCu6pyjz/dzUcqYS3iw1/q+UWyS+SOIaz9sAMd1q8QQwW CKubXtlM6DKdnxxNVV4NkwFIeOF6d1pFiIgojqbsNnkPVaFQDc+u9UkkpevBymwr a0HThxeNkYA6MDWSbxJjPvyy1OO2yERbo9RG2jzOx85j29o=
=d5t3
-----END PGP PUBLIC KEY BLOCK-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is a multi-part message in MIME format.
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.




-----BEGIN PGP PUBLIC KEY BLOCK-----

mQGNBF64/IEBDACVrdj4Yfr7PC/t7tBofnMWWDoWiRxl+Oo64YjsamZGiy0hJHfP ZhI/pnOgqhy6pzsF/8c9Dx9A9SSAJOvC96wMTHgdh4GbffekCwoIXcKZeg9bjXjV Nth5CYOSBTQ9C/pl/j0CwjBQ9mdyK7FoHMlBEmQ4ButtBJgPNjyruiFkBt2r/99u w+hZEt+tO3D69v2MBMVF8pjZWzDDoIsbCUQGtaDD4uAIMqdDl28yw5FeYFg7PKLJ DXft8pNm/4bWv7BizTEVwSkcpPMR/6v/gXUhUsqCoqaWT9oSALmO5l9JfuNk2mpP bjue5joPlpOzaH+ZC0et/eynzyTxOpIAL97g1SVQLqqKRMu3atFda53ZyMNAcH3G R1gV5kX1rM3Ajyw1d7hp1rAYINdB/O/Y8VkNn0j6NZmEi8E1AwK3hu4ZJPIr9FQF bsWmAtjIgO1VXHxvxB7nYF5o7M350hW9SZlkbDf9NWBUHJlc5j4WVEYCjw1C3y8h OwFl1RfDFETqmdUAEQEAAbQrSm9oYW5uIEJlcmV0dGEgPGJlcmV0dGFAbnVuLXlh LWJpem5lc3MuY29tPokB1AQTAQgAPhYhBJx2orrQOL31I0cnEBM/4/Zk8Q8TBQJe uP0PAhsDBQkB4TOABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEBM/4/Zk8Q8T 0KYL/jL1DoQWCMil5EPlLSDG3iByV711VChSpWGbE4m2KrMjMdG0gQBNpg3IChKi tP5/5YdxHGKGjuDxvF/laTq/5KXosNmfdaJr9pmztOWT7tvmlwM+zUR782EQJeeU rGfv6TwYng7TUEaBH86Rg8m6fMKNqSt9MLly+p48Lv8TNj1RofvMv5Ng5xJWkGJ2 +yJ6k61h6Xg8OFY/AEs98OMejDKPq2PTZyH1BQKmyDk82wOGUdSkQoA41aZSckki aXFXIG97NhXY+dcZbOVCjXez0Iujo4vSCbM+x63fX7FyyNsG4f2vPfqhrqNGgrwD KQxYzWgVfvCqKpW6S75l0DfelMFAjM5GcpKs65vRyjRDuMlj6/jSN0O6Os8EOlhr lHBoY1PrBwTX+pBgb1esF2KLbFjfxGLzvbfR85TbYaZi/hohwD/rm+s5QWe03pO/ n85mdVxYAhAhvXsO6s7wfTm0qc/SK7Xp82aYOKVArarNgRIMul7UBo2786ZFhmZY wQGPQ7kBjQReuPzOAQwAoWku3K9ipwwiuH/9C8uUqY1kZy9VW/K7b5uXKww43Dl5 SAFTd+TC8nySqSacHohTQSnd8r3eZgX6az3SR30Y0F6Ftprbx0dkRABKtVzEcxCJ Y2+lqfT6aPIQh+tp/mmWVzrmeYlQNFVLNbu0Tk62K0sedfnhDGgqN4DEWQqgGfG5 Zsj1VcYoXYkt1V/U16GPs75aqWdt+OQmlDb2FQbo/HcsB1bdrE9A7fM39WQpod/k tkAZRJM6RX1f2hJAFwgBEKYieK4ZGfMtgxpIMnvBDwB1FuLw2sGshRtaPO8t0F+w jR/i6PEwCWZSaENhik+oAxDgaKPkxZHpzYS3RM67HoRie1ewuqAw77xeAI4WLbxo +FNg8W+kdPgdRkGeMaYot4hoVGpgF0q0cBPm97wAysxbAu/TDlX/ev4XEkRnZg7k ScCVTrkk9bSVIXs0uB8qkudcudrzokZJ+6v+X5JKgwOMBBSY7sk11T3azog6wxJN BuqS1wB/H4Kht9OMLoTVABEBAAGJAbwEGAEIACYWIQScdqK60Di99SNHJxATP+P2 ZPEPEwUCXrj8zgIbDAUJAeEzgAAKCRATP+P2ZPEPE1UNC/sFAMZnLH8OdDwflfhr iyESWHhRJb1xC4tlJzZ/ufbWY8SbVqO5HbA7EALwW3Ony8SNRRN/OUBw7bM12VPX 0ya6RTQHtPzweL98AnGu0YbyHtKwJrNlGQS0LKWDv4FWQ6f8HxZQt0EzhgRaudGE MHNACuKbxWFpvNAM95LNpLDjRE+DJYGnsDOCRRC4fFRTG0+vqIqgniQzHmn8ddr6 5NazPg07TJzqLjsNBcTCGvRivoRDRP75PnQS8VppnyWubbXJjffmuIG2iqHnY5as ibsSo+TJ+7UEhbNx+uQBKO5KXvG/u9eWgyJz/Uf47zUbG9v9vocbOSbylPHjC3uO ONw91nUHLmGzi3ZmeyPeCu6pyjz/dzUcqYS3iw1/q+UWyS+SOIaz9sAMd1q8QQwW CKubXtlM6DKdnxxNVV4NkwFIeOF6d1pFiIgojqbsNnkPVaFQDc+u9UkkpevBymwr a0HThxeNkYA6MDWSbxJjPvyy1OO2yERbo9RG2jzOx85j29o=
=d5t3
-----END PGP PUBLIC KEY BLOCK-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is a multi-part message in MIME format.
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.


-----BEGIN PGP PUBLIC KEY BLOCK-----

mQGNBF64/IEBDACVrdj4Yfr7PC/t7tBofnMWWDoWiRxl+Oo64YjsamZGiy0hJHfP ZhI/pnOgqhy6pzsF/8c9Dx9A9SSAJOvC96wMTHgdh4GbffekCwoIXcKZeg9bjXjV Nth5CYOSBTQ9C/pl/j0CwjBQ9mdyK7FoHMlBEmQ4ButtBJgPNjyruiFkBt2r/99u w+hZEt+tO3D69v2MBMVF8pjZWzDDoIsbCUQGtaDD4uAIMqdDl28yw5FeYFg7PKLJ DXft8pNm/4bWv7BizTEVwSkcpPMR/6v/gXUhUsqCoqaWT9oSALmO5l9JfuNk2mpP bjue5joPlpOzaH+ZC0et/eynzyTxOpIAL97g1SVQLqqKRMu3atFda53ZyMNAcH3G R1gV5kX1rM3Ajyw1d7hp1rAYINdB/O/Y8VkNn0j6NZmEi8E1AwK3hu4ZJPIr9FQF bsWmAtjIgO1VXHxvxB7nYF5o7M350hW9SZlkbDf9NWBUHJlc5j4WVEYCjw1C3y8h OwFl1RfDFETqmdUAEQEAAbQrSm9oYW5uIEJlcmV0dGEgPGJlcmV0dGFAbnVuLXlh LWJpem5lc3MuY29tPokB1AQTAQgAPhYhBJx2orrQOL31I0cnEBM/4/Zk8Q8TBQJe uP0PAhsDBQkB4TOABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEBM/4/Zk8Q8T 0KYL/jL1DoQWCMil5EPlLSDG3iByV711VChSpWGbE4m2KrMjMdG0gQBNpg3IChKi tP5/5YdxHGKGjuDxvF/laTq/5KXosNmfdaJr9pmztOWT7tvmlwM+zUR782EQJeeU rGfv6TwYng7TUEaBH86Rg8m6fMKNqSt9MLly+p48Lv8TNj1RofvMv5Ng5xJWkGJ2 +yJ6k61h6Xg8OFY/AEs98OMejDKPq2PTZyH1BQKmyDk82wOGUdSkQoA41aZSckki aXFXIG97NhXY+dcZbOVCjXez0Iujo4vSCbM+x63fX7FyyNsG4f2vPfqhrqNGgrwD KQxYzWgVfvCqKpW6S75l0DfelMFAjM5GcpKs65vRyjRDuMlj6/jSN0O6Os8EOlhr lHBoY1PrBwTX+pBgb1esF2KLbFjfxGLzvbfR85TbYaZi/hohwD/rm+s5QWe03pO/ n85mdVxYAhAhvXsO6s7wfTm0qc/SK7Xp82aYOKVArarNgRIMul7UBo2786ZFhmZY wQGPQ7kBjQReuPzOAQwAoWku3K9ipwwiuH/9C8uUqY1kZy9VW/K7b5uXKww43Dl5 SAFTd+TC8nySqSacHohTQSnd8r3eZgX6az3SR30Y0F6Ftprbx0dkRABKtVzEcxCJ Y2+lqfT6aPIQh+tp/mmWVzrmeYlQNFVLNbu0Tk62K0sedfnhDGgqN4DEWQqgGfG5 Zsj1VcYoXYkt1V/U16GPs75aqWdt+OQmlDb2FQbo/HcsB1bdrE9A7fM39WQpod/k tkAZRJM6RX1f2hJAFwgBEKYieK4ZGfMtgxpIMnvBDwB1FuLw2sGshRtaPO8t0F+w jR/i6PEwCWZSaENhik+oAxDgaKPkxZHpzYS3RM67HoRie1ewuqAw77xeAI4WLbxo +FNg8W+kdPgdRkGeMaYot4hoVGpgF0q0cBPm97wAysxbAu/TDlX/ev4XEkRnZg7k ScCVTrkk9bSVIXs0uB8qkudcudrzokZJ+6v+X5JKgwOMBBSY7sk11T3azog6wxJN BuqS1wB/H4Kht9OMLoTVABEBAAGJAbwEGAEIACYWIQScdqK60Di99SNHJxATP+P2 ZPEPEwUCXrj8zgIbDAUJAeEzgAAKCRATP+P2ZPEPE1UNC/sFAMZnLH8OdDwflfhr iyESWHhRJb1xC4tlJzZ/ufbWY8SbVqO5HbA7EALwW3Ony8SNRRN/OUBw7bM12VPX 0ya6RTQHtPzweL98AnGu0YbyHtKwJrNlGQS0LKWDv4FWQ6f8HxZQt0EzhgRaudGE MHNACuKbxWFpvNAM95LNpLDjRE+DJYGnsDOCRRC4fFRTG0+vqIqgniQzHmn8ddr6 5NazPg07TJzqLjsNBcTCGvRivoRDRP75PnQS8VppnyWubbXJjffmuIG2iqHnY5as ibsSo+TJ+7UEhbNx+uQBKO5KXvG/u9eWgyJz/Uf47zUbG9v9vocbOSbylPHjC3uO ONw91nUHLmGzi3ZmeyPeCu6pyjz/dzUcqYS3iw1/q+UWyS+SOIaz9sAMd1q8QQwW CKubXtlM6DKdnxxNVV4NkwFIeOF6d1pFiIgojqbsNnkPVaFQDc+u9UkkpevBymwr a0HThxeNkYA6MDWSbxJjPvyy1OO2yERbo9RG2jzOx85j29o=
=d5t3
-----END PGP PUBLIC KEY BLOCK-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is a multi-part message in MIME format.
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.


-----BEGIN PGP PUBLIC KEY BLOCK-----

mQGNBF64/IEBDACVrdj4Yfr7PC/t7tBofnMWWDoWiRxl+Oo64YjsamZGiy0hJHfP ZhI/pnOgqhy6pzsF/8c9Dx9A9SSAJOvC96wMTHgdh4GbffekCwoIXcKZeg9bjXjV Nth5CYOSBTQ9C/pl/j0CwjBQ9mdyK7FoHMlBEmQ4ButtBJgPNjyruiFkBt2r/99u w+hZEt+tO3D69v2MBMVF8pjZWzDDoIsbCUQGtaDD4uAIMqdDl28yw5FeYFg7PKLJ DXft8pNm/4bWv7BizTEVwSkcpPMR/6v/gXUhUsqCoqaWT9oSALmO5l9JfuNk2mpP bjue5joPlpOzaH+ZC0et/eynzyTxOpIAL97g1SVQLqqKRMu3atFda53ZyMNAcH3G R1gV5kX1rM3Ajyw1d7hp1rAYINdB/O/Y8VkNn0j6NZmEi8E1AwK3hu4ZJPIr9FQF bsWmAtjIgO1VXHxvxB7nYF5o7M350hW9SZlkbDf9NWBUHJlc5j4WVEYCjw1C3y8h OwFl1RfDFETqmdUAEQEAAbQrSm9oYW5uIEJlcmV0dGEgPGJlcmV0dGFAbnVuLXlh LWJpem5lc3MuY29tPokB1AQTAQgAPhYhBJx2orrQOL31I0cnEBM/4/Zk8Q8TBQJe uP0PAhsDBQkB4TOABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEBM/4/Zk8Q8T 0KYL/jL1DoQWCMil5EPlLSDG3iByV711VChSpWGbE4m2KrMjMdG0gQBNpg3IChKi tP5/5YdxHGKGjuDxvF/laTq/5KXosNmfdaJr9pmztOWT7tvmlwM+zUR782EQJeeU rGfv6TwYng7TUEaBH86Rg8m6fMKNqSt9MLly+p48Lv8TNj1RofvMv5Ng5xJWkGJ2 +yJ6k61h6Xg8OFY/AEs98OMejDKPq2PTZyH1BQKmyDk82wOGUdSkQoA41aZSckki aXFXIG97NhXY+dcZbOVCjXez0Iujo4vSCbM+x63fX7FyyNsG4f2vPfqhrqNGgrwD KQxYzWgVfvCqKpW6S75l0DfelMFAjM5GcpKs65vRyjRDuMlj6/jSN0O6Os8EOlhr lHBoY1PrBwTX+pBgb1esF2KLbFjfxGLzvbfR85TbYaZi/hohwD/rm+s5QWe03pO/ n85mdVxYAhAhvXsO6s7wfTm0qc/SK7Xp82aYOKVArarNgRIMul7UBo2786ZFhmZY wQGPQ7kBjQReuPzOAQwAoWku3K9ipwwiuH/9C8uUqY1kZy9VW/K7b5uXKww43Dl5 SAFTd+TC8nySqSacHohTQSnd8r3eZgX6az3SR30Y0F6Ftprbx0dkRABKtVzEcxCJ Y2+lqfT6aPIQh+tp/mmWVzrmeYlQNFVLNbu0Tk62K0sedfnhDGgqN4DEWQqgGfG5 Zsj1VcYoXYkt1V/U16GPs75aqWdt+OQmlDb2FQbo/HcsB1bdrE9A7fM39WQpod/k tkAZRJM6RX1f2hJAFwgBEKYieK4ZGfMtgxpIMnvBDwB1FuLw2sGshRtaPO8t0F+w jR/i6PEwCWZSaENhik+oAxDgaKPkxZHpzYS3RM67HoRie1ewuqAw77xeAI4WLbxo +FNg8W+kdPgdRkGeMaYot4hoVGpgF0q0cBPm97wAysxbAu/TDlX/ev4XEkRnZg7k ScCVTrkk9bSVIXs0uB8qkudcudrzokZJ+6v+X5JKgwOMBBSY7sk11T3azog6wxJN BuqS1wB/H4Kht9OMLoTVABEBAAGJAbwEGAEIACYWIQScdqK60Di99SNHJxATP+P2 ZPEPEwUCXrj8zgIbDAUJAeEzgAAKCRATP+P2ZPEPE1UNC/sFAMZnLH8OdDwflfhr iyESWHhRJb1xC4tlJzZ/ufbWY8SbVqO5HbA7EALwW3Ony8SNRRN/OUBw7bM12VPX 0ya6RTQHtPzweL98AnGu0YbyHtKwJrNlGQS0LKWDv4FWQ6f8HxZQt0EzhgRaudGE MHNACuKbxWFpvNAM95LNpLDjRE+DJYGnsDOCRRC4fFRTG0+vqIqgniQzHmn8ddr6 5NazPg07TJzqLjsNBcTCGvRivoRDRP75PnQS8VppnyWubbXJjffmuIG2iqHnY5as ibsSo+TJ+7UEhbNx+uQBKO5KXvG/u9eWgyJz/Uf47zUbG9v9vocbOSbylPHjC3uO ONw91nUHLmGzi3ZmeyPeCu6pyjz/dzUcqYS3iw1/q+UWyS+SOIaz9sAMd1q8QQwW CKubXtlM6DKdnxxNVV4NkwFIeOF6d1pFiIgojqbsNnkPVaFQDc+u9UkkpevBymwr a0HThxeNkYA6MDWSbxJjPvyy1OO2yERbo9RG2jzOx85j29o=
=d5t3
-----END PGP PUBLIC KEY BLOCK-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)