Do you have a question? Post it now! No Registration Necessary
Subject
- Posted on

Re: Using an RPi 3B+ as a "post office" between two subnets ?

I suggest you re-think your whole setup
your reasoning is flawed from the outset as if a device's on bothe
networks can communicate with the "Post-office" then tha become a vector
for attack between the networks anyway.
But I suspect you are once again forwarding a non-realistic requirement
just to see how many knots you can tie the responders up in.
--
<RoboHak> hmm, lunch does sound like a good idea
<Knghtbrd> would taste like a good idea too
<RoboHak> hmm, lunch does sound like a good idea
<Knghtbrd> would taste like a good idea too

Re: Using an RPi 3B+ as a "post office" between two subnets ?
On 6/28/20 8:45 AM, Alister wrote:

Yes, the bastion can talk to both systems and as such could attack both
systems. But that's not his concern. He has /specifically/ asked for a
way to configure something, a Raspberry Pi in this case, as a way point
between two systems that can't otherwise communicate with each other.

I have seen and supported this multiple-isolated-networks many times.
It doesn't matter /why/ he wants to do it. The fact of the matter is
that he /wants/ to do it.
It is possible to do what he wants to do.
There is no point in passing judgement on him for what he is choosing to do.

Yes, the bastion can talk to both systems and as such could attack both
systems. But that's not his concern. He has /specifically/ asked for a
way to configure something, a Raspberry Pi in this case, as a way point
between two systems that can't otherwise communicate with each other.

I have seen and supported this multiple-isolated-networks many times.
It doesn't matter /why/ he wants to do it. The fact of the matter is
that he /wants/ to do it.
It is possible to do what he wants to do.
There is no point in passing judgement on him for what he is choosing to do.
--
Grant. . . .
unix || die
Grant. . . .
unix || die

Re: Using an RPi 3B+ as a "post office" between two subnets ?
Alister,

Well, feel free to come up with a(ny) solution that /doesn't/ have any
"vector for attack". Go on, try it.

Damn, there I was, thinking I put a rather simple question forward, and even
described how I thought that it could work. But somehow it seems to have
gone be a bit over your head ...
I must say I do not quite understand that. I mean, how hard is it to
imagine a RPi which reads datablocks from one TCP/IP interface and writes it
to the other one (and vise-verse) - and as a result dropping all IP and port
info from either side. That doesn't really sound like rocket-science, now
does it ?
Regards,
Rudy Wieser

Well, feel free to come up with a(ny) solution that /doesn't/ have any
"vector for attack". Go on, try it.

Damn, there I was, thinking I put a rather simple question forward, and even
described how I thought that it could work. But somehow it seems to have
gone be a bit over your head ...
I must say I do not quite understand that. I mean, how hard is it to
imagine a RPi which reads datablocks from one TCP/IP interface and writes it
to the other one (and vise-verse) - and as a result dropping all IP and port
info from either side. That doesn't really sound like rocket-science, now
does it ?
Regards,
Rudy Wieser

Re: Using an RPi 3B+ as a "post office" between two subnets ?

Nope. I don't think that's possible. There will /always/ be something.
The /realistic/ objective is to find a way that absolutely minimizes
the possibility of attack vectors.

Seeing as how we're talking about networking and not the science of
rockets, no, it's not rocket-science.
That being said, what you have described there is decidedly different
than what has been discussed in this thread.
You are now describing something that actively proxies the network
connection between hosts A and C. This is much more akin to NAT and /
or application layer proxies.
Interacting with TCP connections without using an existing TCP/IP stack
*is* quite /complex/. Is it possible, yes. Is it reasonable, I don't
think so.
Now I feel the need to ask: What does "post office" mean to you?
--
Grant. . . .
unix || die
Grant. . . .
unix || die

Re: Using an RPi 3B+ as a "post office" between two subnets ?
Grant,

What are you doing !? You're spoiling my game ! :-)

:-p

Yeah, and thats part of the problem. Its not the first time I notice that
people often, without as much as a thought, going for 10-pound solutions to
hammer a quarter-of-an-inch problem in. It might work, but don't look at
the side effects.

It was always my full intention to use the RPi's full TCP/IP capablilities,
with me just requesting or writing data (and the socket taking care of the
rest). I just wanted to make sure that the datastreams from the two
networks would stay seperate.

Well... Long ago people wrote messages on /paper/, put them in an also
paper "envelope" and .... No, really! :-)
But seriously, in this context I tried to indicate a place where one host
could drop a message, and the other could retrieve it - without them ever
needing to meet. I just didn't want to be more specific than that -
simply because I had no idea what could/would already be available.
Regards,
Rudy Wieser

What are you doing !? You're spoiling my game ! :-)

:-p

Yeah, and thats part of the problem. Its not the first time I notice that
people often, without as much as a thought, going for 10-pound solutions to
hammer a quarter-of-an-inch problem in. It might work, but don't look at
the side effects.

It was always my full intention to use the RPi's full TCP/IP capablilities,
with me just requesting or writing data (and the socket taking care of the
rest). I just wanted to make sure that the datastreams from the two
networks would stay seperate.

Well... Long ago people wrote messages on /paper/, put them in an also
paper "envelope" and .... No, really! :-)
But seriously, in this context I tried to indicate a place where one host
could drop a message, and the other could retrieve it - without them ever
needing to meet. I just didn't want to be more specific than that -
simply because I had no idea what could/would already be available.
Regards,
Rudy Wieser

Re: Using an RPi 3B+ as a "post office" between two subnets ?
On 6/28/20 12:54 PM, R.Wieser wrote:

Sorry!!!

~chuckle~
I've used a 10-pound hammer to push in a thumb tack. But that was an
extremely atypical use of said hammer and I didn't swing it.
The tool, and more importantly, how it's used, is EXTREMELY important.

Okay. That sounds like you're headed towards the realm of an
Application Layer Gateway / Proxy.

Paper? I thought it was a stone tablet.

That's what I thought. But such a drop box / post office is decidedly
different than the ALG that it sounds like you're headed towards.

Sorry!!!

~chuckle~
I've used a 10-pound hammer to push in a thumb tack. But that was an
extremely atypical use of said hammer and I didn't swing it.
The tool, and more importantly, how it's used, is EXTREMELY important.

Okay. That sounds like you're headed towards the realm of an
Application Layer Gateway / Proxy.

Paper? I thought it was a stone tablet.

That's what I thought. But such a drop box / post office is decidedly
different than the ALG that it sounds like you're headed towards.
--
Grant. . . .
unix || die
Grant. . . .
unix || die

Re: Using an RPi 3B+ as a "post office" between two subnets ?
declaimed the following:

As described, you have an ACTIVE PROCESS running on the R-Pi. Since the
TCP/IP interface uses source IP:port/destination IP:port (where destination
is the R-Pi) to define a connection, your active process will have to
maintain a table mapping the source:R-Pi connections to
R-Pi:other-destination. That is what a NAT router is performing! And, below
IP/port -- packets are routed by MAC address (the hardware address of
interface itself -- one interface can have multiple IP numbers assigned to
it, each of which can have many ports active)
If you are trying to sanitize the data "dropping IP/port" you are now
looking at the aforementioned "data diode" operation. Those are designed so
that only certain packets are allowed through, and often use fiber optics
between the two sides to ensure that there is NO wired connection (some may
also be unidirectional -- data from the secure side is sanitized (some can
actually edit out parts of the packet if the packet format is set up) and
sent out on the unsecured side, but the unsecured side can not send data to
the secure side.
Your original post implied the R-Pi would be a more passive device. One
side would dump a file to (a directory on an R-Pi storage device --
recommend USB drive if this is busy system, to avoid SD card failure), At
some later time the other side would retrieve the file from the R-Pi.
THAT form of operation is easily done using FTP (deprecated in the wild
as the log-on information is sent in the clear) or sFTP (which is already
running on an R-Pi if you have SSH enabled).
On the R-Pi, create a set of users/passwords (at minimum, one for each
side, at most one per external machine). Set these users for very minimal
privileges -- basically put them in a "post office group" and set the
storage directories to be RW for users in this "post office group". Also
set the home directory for those users to the top of the post office
directory tree.
Source host can sFTP using its login credentials, PUT the data file.
Destination host, at some later time will sFTP with its credentials at some
later time, check for new files, GET those files, and then DELETE the
files.


As described, you have an ACTIVE PROCESS running on the R-Pi. Since the
TCP/IP interface uses source IP:port/destination IP:port (where destination
is the R-Pi) to define a connection, your active process will have to
maintain a table mapping the source:R-Pi connections to
R-Pi:other-destination. That is what a NAT router is performing! And, below
IP/port -- packets are routed by MAC address (the hardware address of
interface itself -- one interface can have multiple IP numbers assigned to
it, each of which can have many ports active)
If you are trying to sanitize the data "dropping IP/port" you are now
looking at the aforementioned "data diode" operation. Those are designed so
that only certain packets are allowed through, and often use fiber optics
between the two sides to ensure that there is NO wired connection (some may
also be unidirectional -- data from the secure side is sanitized (some can
actually edit out parts of the packet if the packet format is set up) and
sent out on the unsecured side, but the unsecured side can not send data to
the secure side.
Your original post implied the R-Pi would be a more passive device. One
side would dump a file to (a directory on an R-Pi storage device --
recommend USB drive if this is busy system, to avoid SD card failure), At
some later time the other side would retrieve the file from the R-Pi.
THAT form of operation is easily done using FTP (deprecated in the wild
as the log-on information is sent in the clear) or sFTP (which is already
running on an R-Pi if you have SSH enabled).
On the R-Pi, create a set of users/passwords (at minimum, one for each
side, at most one per external machine). Set these users for very minimal
privileges -- basically put them in a "post office group" and set the
storage directories to be RW for users in this "post office group". Also
set the home directory for those users to the top of the post office
directory tree.
Source host can sFTP using its login credentials, PUT the data file.
Destination host, at some later time will sFTP with its credentials at some
later time, check for new files, GET those files, and then DELETE the
files.

--
Wulfraed Dennis Lee Bieber AF6VN
snipped-for-privacy@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
Wulfraed Dennis Lee Bieber AF6VN
snipped-for-privacy@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

Re: Using an RPi 3B+ as a "post office" between two subnets ?

I think we have different understandings of what "data diode" is and does.
To me, a "data diode" is a one way flow control device (much like the
electrical component that only allows current flow in one direction).

When you start talking about conditionally allowing data to flow or not
flow (in one or both directions) you start getting into a firewall that
filters traffic based on IP and / or protocol and / or port and / or state.

This sounds more like a firewall combined with a "data diode".

Agreed.
There are many ways to achieve this simple data drop / post office
functionality.

Now you get into multi-user access to the data drop / post office and
what they can see (read) / modify (write) / delete (also write). This
quickly devolves into a deep and dark rabbit hole.

Yes, this the basic operation of a queuing mechanism.
--
Grant. . . .
unix || die
Grant. . . .
unix || die

Re: Using an RPi 3B+ as a "post office" between two subnets ?
Denis,

Either you are describing that as something special when every other 'puter
does the same, or you have read something I've never said.
But to make it absolutily clear, in my explanation the RPi is *passive*. It
waits for connections initiated by both hosts, and only than tries to / can
write received packets to the other interface.

Nope. Both sides can send and both sides can receive. The only thing that
happens in the RPi is that the connection gets scrubbed (notice: the
connection, not its data).

As in the above, it is supposed to be.

....
Why is it that "passive" also must mean "time delay" and (thus?) "files" ?
I don't get it.

as well as for its multi-port usage ofcourse, which doesn't work well with
(simple) firewalls.
But as mentioned, I had something /much/ simpler in mind - with the RPi
being next to invisible.
Doesn't mean that I cannot also think of setting the RPi up as a
multi-subnet data-storage device ofcourse. Heck, I might even think of
setting up both !
Regards,
Rudy Wieser

Either you are describing that as something special when every other 'puter
does the same, or you have read something I've never said.
But to make it absolutily clear, in my explanation the RPi is *passive*. It
waits for connections initiated by both hosts, and only than tries to / can
write received packets to the other interface.

Nope. Both sides can send and both sides can receive. The only thing that
happens in the RPi is that the connection gets scrubbed (notice: the
connection, not its data).

As in the above, it is supposed to be.

....
Why is it that "passive" also must mean "time delay" and (thus?) "files" ?
I don't get it.

as well as for its multi-port usage ofcourse, which doesn't work well with
(simple) firewalls.
But as mentioned, I had something /much/ simpler in mind - with the RPi
being next to invisible.
Doesn't mean that I cannot also think of setting the RPi up as a
multi-subnet data-storage device ofcourse. Heck, I might even think of
setting up both !
Regards,
Rudy Wieser

Re: Using an RPi 3B+ as a "post office" between two subnets ?
On 6/28/20 2:10 PM, R.Wieser wrote:

I think we have a nomenclature problem here.
I think you, R. Wieser, are using "passive" as a reference to which host
/initiates/ the connection.
Where as some people in this thread have taken "active" vs "passive" to
mean "doing something with the traffic to copy it from one interface to
another".
Traditionally, in both computers and electronics, a passive device is
one that will function without any power, conversely an active device
will not function without power.
A DB-25 to RJ-45 adapter is passive in that it's wires and unpowered.
Conversely, a Pi is an active device that will not function without power.
So, we get into the minutia of /what/ /specifically/ the Pi is doing and
if it constitutes active or passive.
I think that many would support that routers, particularly routers that
alter traffic as it passes through, are /active/ devices.
You have stated that you want to /actively/ decide what traffic to allow
through or not.
You have also stated that you want software to read from one interface
and write to another interface. Both of those are active functions.
Even if you don't consider traditional routing to be active, you have
indicated that you are considering writing a custom program to read from
one interface and write to another, possibly via sockets with the
existing TCP/IP stack. This sounds very active to me.
The Pi can be both active in that it processes traffic and /reactive/ in
that it only does so in response to external stimuli.
So, please clarify what you mean by "active" vs "passive" as well as
"initiator" and "responder". Please also re-state your desires while
clearly indicating what is active / passive and initiator / responder.

The "scrubbing" supports some sort of active process on the connection.
Connection vs data is getting into the minutia and we need to share a
common understanding of what each other means. Lest we talk in circles
around each other.

Unless or until corrected, I'm going to take "passive" to mean "does not
initiate / responds to external initiation".

In typical file drop / post office scenarios, the recipient can't
/safely/ read the file until /after/ the file is completely written. As
such, you are introducing a delay of some amount of time.
Conversely, an active process can read from one socket and write to
another socket in almost parallel. (There is a tiny but measurable
delay.) It can certainly start writing to the second socket before the
data is finished being written to the first socket.

If by "simple" you mean "stateless", sure.

I'm not convinced that the Pi will be as invisible as I think you are
thinking.
Hosts A and C will know the remote IP that they are talking to. They
can share that information in the data that passes between them (much
like FTP does) and can detect that each other are not at the addresses
they are talking to.
Does this visibility matter? Probably not. But it might.

~chuckle~

I think we have a nomenclature problem here.
I think you, R. Wieser, are using "passive" as a reference to which host
/initiates/ the connection.
Where as some people in this thread have taken "active" vs "passive" to
mean "doing something with the traffic to copy it from one interface to
another".
Traditionally, in both computers and electronics, a passive device is
one that will function without any power, conversely an active device
will not function without power.
A DB-25 to RJ-45 adapter is passive in that it's wires and unpowered.
Conversely, a Pi is an active device that will not function without power.
So, we get into the minutia of /what/ /specifically/ the Pi is doing and
if it constitutes active or passive.
I think that many would support that routers, particularly routers that
alter traffic as it passes through, are /active/ devices.
You have stated that you want to /actively/ decide what traffic to allow
through or not.
You have also stated that you want software to read from one interface
and write to another interface. Both of those are active functions.
Even if you don't consider traditional routing to be active, you have
indicated that you are considering writing a custom program to read from
one interface and write to another, possibly via sockets with the
existing TCP/IP stack. This sounds very active to me.
The Pi can be both active in that it processes traffic and /reactive/ in
that it only does so in response to external stimuli.
So, please clarify what you mean by "active" vs "passive" as well as
"initiator" and "responder". Please also re-state your desires while
clearly indicating what is active / passive and initiator / responder.

The "scrubbing" supports some sort of active process on the connection.
Connection vs data is getting into the minutia and we need to share a
common understanding of what each other means. Lest we talk in circles
around each other.

Unless or until corrected, I'm going to take "passive" to mean "does not
initiate / responds to external initiation".

In typical file drop / post office scenarios, the recipient can't
/safely/ read the file until /after/ the file is completely written. As
such, you are introducing a delay of some amount of time.
Conversely, an active process can read from one socket and write to
another socket in almost parallel. (There is a tiny but measurable
delay.) It can certainly start writing to the second socket before the
data is finished being written to the first socket.

If by "simple" you mean "stateless", sure.

I'm not convinced that the Pi will be as invisible as I think you are
thinking.
Hosts A and C will know the remote IP that they are talking to. They
can share that information in the data that passes between them (much
like FTP does) and can detect that each other are not at the addresses
they are talking to.
Does this visibility matter? Probably not. But it might.

~chuckle~
--
Grant. . . .
unix || die
Grant. . . .
unix || die

Re: Using an RPi 3B+ as a "post office" between two subnets ?
Grant,

Yeah, I also got that rather strong feeling, which is why I mentioned the
above. To allow you to become aware of my usage of the word (and context),
and invite you to mention yours. As you did.

:-) Look at the package-exchanging method I described. Although the Pi is
not attempting to do /anything/ to those packets, the end result is still
that the data connection (between A and C) is scrubbed. Now, tell me if
that means the Pi is "passive", or "active" :-)
IOW, the definition of the word "passive" (and "active" ofcourse) is
strongly tied to the context:
Using my described method to shuttle datapackets to-and-fro:
- The Pi is passive because it does not initiate connections to either A or
C
- The Pi is passive because it does not attempt to alter the datapackets it
exchanges between the two sockets.
- From the POV of A and C the Pi is active, as it scrubs the datastream
between them.
And I'm sure I forgot a few POVs :-)

I'm sorry, but I never mentioned anything of the kind (I read that
"actively decide" as "runtime" as opposed to "design time")
Also, as we are observing nomenclature, what does "traffic" mean to you ?
Everything that goes over the ethernet cable (or comparable), or perhaps
just the data thats left when all the different headers are peeled away ?
Maybe even something in between ? And yeah, that does make (quite) a
difference I'm afraid. :-)

And there you have yet another context in which "passive" or its counterpart
"active" can be used. On the other hand, can you make the RPi actually /do/
anything while its "passive" (not running any kind of program) ? Other
than being a paperweight of some sort I mean.
I'm going to stop this here though, this is getting silly. The next thing
we do is discussing what the definition of "is" is. :-(

How do they detect that ? You seem to assume that A and C know each
others IPs. Why ? What would that be good for ?
And even if they would know, there is no way they can reach each other. As
you said it, if they could than this whole conversation would be moot (and a
big waste of time).
Regards,
Rudy Wieser

Yeah, I also got that rather strong feeling, which is why I mentioned the
above. To allow you to become aware of my usage of the word (and context),
and invite you to mention yours. As you did.

:-) Look at the package-exchanging method I described. Although the Pi is
not attempting to do /anything/ to those packets, the end result is still
that the data connection (between A and C) is scrubbed. Now, tell me if
that means the Pi is "passive", or "active" :-)
IOW, the definition of the word "passive" (and "active" ofcourse) is
strongly tied to the context:
Using my described method to shuttle datapackets to-and-fro:
- The Pi is passive because it does not initiate connections to either A or
C
- The Pi is passive because it does not attempt to alter the datapackets it
exchanges between the two sockets.
- From the POV of A and C the Pi is active, as it scrubs the datastream
between them.
And I'm sure I forgot a few POVs :-)

I'm sorry, but I never mentioned anything of the kind (I read that
"actively decide" as "runtime" as opposed to "design time")
Also, as we are observing nomenclature, what does "traffic" mean to you ?
Everything that goes over the ethernet cable (or comparable), or perhaps
just the data thats left when all the different headers are peeled away ?
Maybe even something in between ? And yeah, that does make (quite) a
difference I'm afraid. :-)

And there you have yet another context in which "passive" or its counterpart
"active" can be used. On the other hand, can you make the RPi actually /do/
anything while its "passive" (not running any kind of program) ? Other
than being a paperweight of some sort I mean.
I'm going to stop this here though, this is getting silly. The next thing
we do is discussing what the definition of "is" is. :-(

How do they detect that ? You seem to assume that A and C know each
others IPs. Why ? What would that be good for ?
And even if they would know, there is no way they can reach each other. As
you said it, if they could than this whole conversation would be moot (and a
big waste of time).
Regards,
Rudy Wieser

Re: Using an RPi 3B+ as a "post office" between two subnets ?
On 6/29/20 3:47 AM, R.Wieser wrote:

The Pi is is actively doing something to copy packets from one socket to
another. Packets won't flow between the sockets if there isn't
something doing the copy. That something is the active part.
This is also why I think routers are active. Same concept, just at an
interface level vs a socket level.

Agreed.
I agree that the Pi doesn't /initiate/ the socket connections.
But as previously stated, simply establishing a socket connection from A
to B and C to B is not enough. Something on the Pi must copy packets
from socket to socket. Thus why I state that the Pi is actively doing
something with the data on the sockets.
An analogy. Suppose that two directors in the company have a Jr. staff
person go down and check their mailboxes in the mail room. The first
director has the staffer take a memo and put it in the out box in the
mail room and check the first directors mail box. The second director
does similar. Without the 3rd employee in the mail room taking the mail
out of the out box and putting it in the respective directors inbox,
there will never be any mail for the staffer to pick up and bring back
to their respective directors. This 3rd person, working in the mail
room, is actively doing /something/ with the mail. What is being done
can be debated later. But the fact remains, that without this 3rd
person actively doing something with mail, communications will not flow
between directors.
The Pi in your scenario is the 3rd person in the mail room actively
moving things between mail boxes.
As I type this, I realize that there is a slight variation that might be
what you're thinking. If the staffers put the outgoing memos directly
into the recipient's mailbox (the staffers do the routing) there might
not be a need for the 3rd employee. However, that is a different
process than is happening above. It also requires that the staffer do
more work. It also means that the staffers must have access to all of
the recipient's mailboxes.

I disagree. See above. The packets (messages) don't go from one
mailbox (socket) to another without the mail room employee moving them.
The mail room employee does not need to open and scrutinize the
messages. Something that would be invasive and extremely active. The
simple act of taking messages from mailbox (socket) 1 and putting them
in mailbox (socket) 2 is an active process. It's just less active than
reading and spell / grammar checking it.

That's somewhat an incidental side effect that a shoe box shaped package
won't fit in a letter slot, thus gets dropped on the floor.

You have stated that only traffic of your choosing will be forwarded.
That means that there is a selection criteria to make the decision of if
something is forwarded or not. Given above about the active mail room
employee, that is an "active decision" (per packet).

Traffic is anything that the host sends. Some of it will make it
through the Pi, some of it will not. Depending on shape.

No. The Pi won't do anything productive while being passive. Even
running the kernel or receiving files into a queue is a form of active
action. The Pi won't do anything when it's powered off, or in
paperweight mode.

Take a look at FTP and SIP for a couple examples.

You will see that FTP and SIP both want to connect to the address that's
inside the data that is passed, not the address of where the apparent
connection is coming from.

The Pi is is actively doing something to copy packets from one socket to
another. Packets won't flow between the sockets if there isn't
something doing the copy. That something is the active part.
This is also why I think routers are active. Same concept, just at an
interface level vs a socket level.

Agreed.
I agree that the Pi doesn't /initiate/ the socket connections.
But as previously stated, simply establishing a socket connection from A
to B and C to B is not enough. Something on the Pi must copy packets
from socket to socket. Thus why I state that the Pi is actively doing
something with the data on the sockets.
An analogy. Suppose that two directors in the company have a Jr. staff
person go down and check their mailboxes in the mail room. The first
director has the staffer take a memo and put it in the out box in the
mail room and check the first directors mail box. The second director
does similar. Without the 3rd employee in the mail room taking the mail
out of the out box and putting it in the respective directors inbox,
there will never be any mail for the staffer to pick up and bring back
to their respective directors. This 3rd person, working in the mail
room, is actively doing /something/ with the mail. What is being done
can be debated later. But the fact remains, that without this 3rd
person actively doing something with mail, communications will not flow
between directors.
The Pi in your scenario is the 3rd person in the mail room actively
moving things between mail boxes.
As I type this, I realize that there is a slight variation that might be
what you're thinking. If the staffers put the outgoing memos directly
into the recipient's mailbox (the staffers do the routing) there might
not be a need for the 3rd employee. However, that is a different
process than is happening above. It also requires that the staffer do
more work. It also means that the staffers must have access to all of
the recipient's mailboxes.

I disagree. See above. The packets (messages) don't go from one
mailbox (socket) to another without the mail room employee moving them.
The mail room employee does not need to open and scrutinize the
messages. Something that would be invasive and extremely active. The
simple act of taking messages from mailbox (socket) 1 and putting them
in mailbox (socket) 2 is an active process. It's just less active than
reading and spell / grammar checking it.

That's somewhat an incidental side effect that a shoe box shaped package
won't fit in a letter slot, thus gets dropped on the floor.

You have stated that only traffic of your choosing will be forwarded.
That means that there is a selection criteria to make the decision of if
something is forwarded or not. Given above about the active mail room
employee, that is an "active decision" (per packet).

Traffic is anything that the host sends. Some of it will make it
through the Pi, some of it will not. Depending on shape.

No. The Pi won't do anything productive while being passive. Even
running the kernel or receiving files into a queue is a form of active
action. The Pi won't do anything when it's powered off, or in
paperweight mode.

Take a look at FTP and SIP for a couple examples.

You will see that FTP and SIP both want to connect to the address that's
inside the data that is passed, not the address of where the apparent
connection is coming from.
--
Grant. . . .
unix || die
Grant. . . .
unix || die

Re: Using an RPi 3B+ as a "post office" between two subnets ?
declaimed the following:

Which is an active process -- somehow you need to implement a protocol
in which one side can say "I want to transfer data to other side" AND the
other side has to say "I want to receive data from the first side"...
Somehow you will have to be able to specify the identification of this
channel AND you will have to maintain the address translation table (source
IP/Port <> destination IP/Port) for these packets. BUT, unlike a NAT
router, you don't want the router part to initiate the gateway operation
(in a router, your computer says "I want to connect to some external mode",
the router takes the information (IP/Port) of the destination, swaps out
the source IP/Port replacing it with a router NAT IP/Port (ie; the
external/ISP assigned IP address, and some unused port on the router), and
updates the NAT table. The external device then sends ACKs and return data
(if any) to the IP/port the router gave it, the router than replaces its
IP/port with the internal device IP/port (per the NAT table).
The external host never sees the IP/port of the internal host, only the
IP/port given by the middleman router.
"Post office"/"mailbox" systems rely on buffering sent traffic locally,
until the recipient connects and takes the stuff out of the mailbox.
I know of nothing that does gateway type operations but only when both
external sides have issued a connection request to the middleware. You're
going to have define the full protocol of this middleware, along with
client software running on the external nodes to initiate the connections
and handle transfer and error conditions. You will NOT have just ad-hoc
(eg: any TCP/IP protocol) to go from one node to another.

NAT router... Not just a gateway (gateways don't mask IP addresses,
they just forward stuff coming in on one interface that is not addressed to
the local machine through to the next specified interface).
A NAT router does the IP/Port substitution, but has to maintain the
status of active connections, error retries, etc. (Note that the NAT
affects the "outgoing" side of the middle -- the source side still has to
know the IP of the destination.
What you do NOT get is the concept that both sides connect to the
middle and negotiate a connection. For that you are going to have to create
a custom NAT system in which SOME type of packet says "I want to connect to
some service port of some named device" [using "names" without using DNS
name->IP lookups]. I say "service port" as typically the source will be
asking to connect to a server running on a known port number... The source
client, however, normally uses an "random" port number -- which complicates
matters as the other side can't say "connect to port-X of other named
device.

Which is an active process -- somehow you need to implement a protocol
in which one side can say "I want to transfer data to other side" AND the
other side has to say "I want to receive data from the first side"...
Somehow you will have to be able to specify the identification of this
channel AND you will have to maintain the address translation table (source
IP/Port <> destination IP/Port) for these packets. BUT, unlike a NAT
router, you don't want the router part to initiate the gateway operation
(in a router, your computer says "I want to connect to some external mode",
the router takes the information (IP/Port) of the destination, swaps out
the source IP/Port replacing it with a router NAT IP/Port (ie; the
external/ISP assigned IP address, and some unused port on the router), and
updates the NAT table. The external device then sends ACKs and return data
(if any) to the IP/port the router gave it, the router than replaces its
IP/port with the internal device IP/port (per the NAT table).
The external host never sees the IP/port of the internal host, only the
IP/port given by the middleman router.
"Post office"/"mailbox" systems rely on buffering sent traffic locally,
until the recipient connects and takes the stuff out of the mailbox.
I know of nothing that does gateway type operations but only when both
external sides have issued a connection request to the middleware. You're
going to have define the full protocol of this middleware, along with
client software running on the external nodes to initiate the connections
and handle transfer and error conditions. You will NOT have just ad-hoc
(eg: any TCP/IP protocol) to go from one node to another.

NAT router... Not just a gateway (gateways don't mask IP addresses,
they just forward stuff coming in on one interface that is not addressed to
the local machine through to the next specified interface).
A NAT router does the IP/Port substitution, but has to maintain the
status of active connections, error retries, etc. (Note that the NAT
affects the "outgoing" side of the middle -- the source side still has to
know the IP of the destination.
What you do NOT get is the concept that both sides connect to the
middle and negotiate a connection. For that you are going to have to create
a custom NAT system in which SOME type of packet says "I want to connect to
some service port of some named device" [using "names" without using DNS
name->IP lookups]. I say "service port" as typically the source will be
asking to connect to a server running on a known port number... The source
client, however, normally uses an "random" port number -- which complicates
matters as the other side can't say "connect to port-X of other named
device.
--
Wulfraed Dennis Lee Bieber AF6VN
snipped-for-privacy@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
Wulfraed Dennis Lee Bieber AF6VN
snipped-for-privacy@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

Re: Using an RPi 3B+ as a "post office" between two subnets ?
On 29/06/2020 04:23, Dennis Lee Bieber wrote:

The OP hasn't stated exactly what applications and/or protocols are
required for this "post office", but if files are sufficient, you could
use OwnCloud (roll your own Dropbox). This would allow files to be kept
synchronised between machines but with no direct network connection
between them. The Pi runs the OwnCloud service and accepts connections
from each network interface, but does not route any data between the
interfaces.
---druck

The OP hasn't stated exactly what applications and/or protocols are
required for this "post office", but if files are sufficient, you could
use OwnCloud (roll your own Dropbox). This would allow files to be kept
synchronised between machines but with no direct network connection
between them. The Pi runs the OwnCloud service and accepts connections
from each network interface, but does not route any data between the
interfaces.
---druck

Re: Using an RPi 3B+ as a "post office" between two subnets ?
On 29/06/2020 08:51, Andy Burns wrote:

Well as my suggestion has been ignored by the OP in favour of continuing
arguments in other parts of thread, I think we can gauge the validity of
the request, and update our kill files accordingly.
--druck

Well as my suggestion has been ignored by the OP in favour of continuing
arguments in other parts of thread, I think we can gauge the validity of
the request, and update our kill files accordingly.
--druck
Site Timeline
- » BMP180 Barometric pressure sensor - deviates about 8 full points from expected
- — Next thread in » Raspberry Pi Group
-
- » BMP180 barometric sensor (I2C) not detected.
- — Previous thread in » Raspberry Pi Group
-
- » My darn NAS UPDATE...
- — Newest thread in » Raspberry Pi Group
-
- » Battery Powered Project
- — Last Updated thread in » Raspberry Pi Group
-
- » continuo comparatore a finestra OK
- — The site's Newest Thread. Posted in » Electronics Hobby (Italian)
-
- » Basette millefori 230 x 160 dove trovarle ?
- — The site's Last Updated Thread. Posted in » Electronics Hobby (Italian)
-