17 Aug
2023
17 Aug
'23
5:21 a.m.
So Mark (Matlock) has been after me to get my HECnet connection up and running and me,
being an ace procrastinator, has always said "Real Soon Now™", Mark.
I might actually have time to do it as I'm on vacation for a week and a half. Despite
the heat I could set something up. My question is how do I set it up. I have a Mac Mini
in Las Vegas running VMWare ESXi. I have a VM (Aniketos) running Vyos for a
firewall/router, another VM with an Nginx web server (Hermes - irrelevant just mentioned
for completeness) and a really small (1 vCPU) Linux VM (Knight) which I want to run
Paul's PyDECnet router for the world to connect to. From there I have an IPSec VPN to
my Ubiquiti EdgeRouter 4 at home. How can I connect DECnet through the VPN to Knight from
home? Is it even possible? Do I need or want GRE tunnels through the VPN?
Am I just making it too complicated and should I set up a PyDECnet router at home and go
that way through my dynamic IP? It's possible I could set up an x86 OpenVMS machine as
another VM
I'm thinking I need a PyDECnet router at home to collect all the DECnet traffic and
shove it through the VPN to the PyDECnet router at the remote site and from there out into
the internet to it's HECnet connection points. Does that make sense?
I tried drawing an ASCII picture but apparently I suck at that. Hopefully the description
makes sense.
Hoping to get people's thoughts and if you're experienced in designing PyDECnet
config files, any pointers are welcome.
--
John H. Reinhardt
17 Aug
17 Aug
5:58 a.m.
You might be making it too complicated.
A home node running PyDECnet, with your dynamic IP address should be
enough. You need someone to connect to, and you both agree on some
parameters, and you configure nodes on your side with the correct DECnet
addresses, and off you go.
Johnny
On 2023-08-17 05:21, John H. Reinhardt wrote:
So Mark (Matlock) has been after me to get my HECnet
connection up and
running and me, being an ace procrastinator, has always said "Real Soon
Now™", Mark.
I might actually have time to do it as I'm on vacation for a week and a
half. Despite the heat I could set something up. My question is how do
I set it up. I have a Mac Mini in Las Vegas running VMWare ESXi. I
have a VM (Aniketos) running Vyos for a firewall/router, another VM with
an Nginx web server (Hermes - irrelevant just mentioned for
completeness) and a really small (1 vCPU) Linux VM (Knight) which I want
to run Paul's PyDECnet router for the world to connect to. From there I
have an IPSec VPN to my Ubiquiti EdgeRouter 4 at home. How can I
connect DECnet through the VPN to Knight from home? Is it even
possible? Do I need or want GRE tunnels through the VPN?
Am I just making it too complicated and should I set up a PyDECnet
router at home and go that way through my dynamic IP? It's possible I
could set up an x86 OpenVMS machine as another VM
I'm thinking I need a PyDECnet router at home to collect all the DECnet
traffic and shove it through the VPN to the PyDECnet router at the
remote site and from there out into the internet to it's HECnet
connection points. Does that make sense?
I tried drawing an ASCII picture but apparently I suck at that.
Hopefully the description makes sense.
Hoping to get people's thoughts and if you're experienced in designing
PyDECnet config files, any pointers are welcome.
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
3:02 p.m.
On Aug 16, 2023, at 11:21 PM, John H. Reinhardt
<johnhreinhardt(a)thereinhardts.org> wrote:
So Mark (Matlock) has been after me to get my HECnet connection up and running and me,
being an ace procrastinator, has always said "Real Soon Now™", Mark.
I might actually have time to do it as I'm on vacation for a week and a half.
Despite the heat I could set something up. My question is how do I set it up. I have a
Mac Mini in Las Vegas running VMWare ESXi. I have a VM (Aniketos) running Vyos for a
firewall/router, another VM with an Nginx web server (Hermes - irrelevant just mentioned
for completeness) and a really small (1 vCPU) Linux VM (Knight) which I want to run
Paul's PyDECnet router for the world to connect to. From there I have an IPSec VPN to
my Ubiquiti EdgeRouter 4 at home. How can I connect DECnet through the VPN to Knight from
home? Is it even possible? Do I need or want GRE tunnels through the VPN?
Am I just making it too complicated and should I set up a PyDECnet router at home and go
that way through my dynamic IP? It's possible I could set up an x86 OpenVMS machine as
another VM
I'm thinking I need a PyDECnet router at home to collect all the DECnet traffic and
shove it through the VPN to the PyDECnet router at the remote site and from there out into
the internet to it's HECnet connection points. Does that make sense?
A router at home that uses the dynamic IP address is certainly a valid option, one a bunch
of us use today.
I don't know that anyone has tried running a DECnet circuit through an IPSec VPN, but
clearly it should work. You'd just point the DECnet circuit to the IP address of the
other end of the tunnel, with the local address of the circuit set to the local endpoint
of the tunnel. Then you can use any IP based communication method that is enabled by the
filter rules of the VPN. For example, if the VPN allows any IP traffic, you could use
anything IP based, from GRE to Multinet to DDCMP. If you want to be more restrictive, you
could enable just the one protocol and port you want. For example, that could be TCP on
which you run Multinet, or TCP or UPD carrying DDCMP.
If you do go this VPN route it would be interesting to hear how it works for you,
especially if you run into problems.
paul
6:25 p.m.
On 8/17/2023 8:02 AM, Paul Koning wrote:
Thanks Johnny and Paul!
I do at least want to try the connection through the VPN. I'm curious if it works as
well. The VPN connection has been very reliable for TCP traffic but it's not heavily
loaded. I keep a "top" session running on each system there just to see if/when
it breaks. It has typically gone months without a problem other than when we have had
extended power outages or my local internet has gone down.
I don't have Multinet anywhere (yet) so I will try the DDCMP via TCP. That seems the
most reasonable place to start.
John H. Reinhardt
On Aug 16, 2023, at 11:21 PM, John H. Reinhardt
<johnhreinhardt(a)thereinhardts.org> wrote:
So Mark (Matlock) has been after me to get my HECnet connection up and running and me,
being an ace procrastinator, has always said "Real Soon Now™", Mark.
I might actually have time to do it as I'm on vacation for a week and a half.
Despite the heat I could set something up. My question is how do I set it up. I have a
Mac Mini in Las Vegas running VMWare ESXi. I have a VM (Aniketos) running Vyos for a
firewall/router, another VM with an Nginx web server (Hermes - irrelevant just mentioned
for completeness) and a really small (1 vCPU) Linux VM (Knight) which I want to run
Paul's PyDECnet router for the world to connect to. From there I have an IPSec VPN to
my Ubiquiti EdgeRouter 4 at home. How can I connect DECnet through the VPN to Knight from
home? Is it even possible? Do I need or want GRE tunnels through the VPN?
Am I just making it too complicated and should I set up a PyDECnet router at home and go
that way through my dynamic IP? It's possible I could set up an x86 OpenVMS machine as
another VM
I'm thinking I need a PyDECnet router at home to collect all the DECnet traffic and
shove it through the VPN to the PyDECnet router at the remote site and from there out into
the internet to it's HECnet connection points. Does that make sense?
A router
at home that uses the dynamic IP address is certainly a valid option, one a bunch of us
use today.
I don't know that anyone has tried running a DECnet circuit through an IPSec VPN, but
clearly it should work. You'd just point the DECnet circuit to the IP address of the
other end of the tunnel, with the local address of the circuit set to the local endpoint
of the tunnel. Then you can use any IP based communication method that is enabled by the
filter rules of the VPN. For example, if the VPN allows any IP traffic, you could use
anything IP based, from GRE to Multinet to DDCMP. If you want to be more restrictive, you
could enable just the one protocol and port you want. For example, that could be TCP on
which you run Multinet, or TCP or UPD carrying DDCMP.
If you do go this VPN route it would be interesting to hear how it works for you,
especially if you run into problems.
paul
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
6:36 p.m.
On Aug 17, 2023, at 12:25 PM, John H. Reinhardt
<johnhreinhardt(a)thereinhardts.org> wrote:
...
I don't have Multinet anywhere (yet) so I will try the DDCMP via TCP. That seems the
most reasonable place to start.
Yes, though DDCMP over UDP also works well; it's become my default choice.
paul
6:40 p.m.
On 2023-08-17 18:36, Paul Koning wrote:
Say what? Did you think something in reverse here, Paul?
I thought we had agreed that DDCMP over UDP is the worst idea. TCP makes
total sense, but UDP means you can get reordering, duplication and lost
packets galore.
Or are you thinking of using something that addds the whole DDCMP
protocol on top of UDP? Doable. Maybe something in PyDECnet I have
forgotten?
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Aug 17, 2023, at 12:25 PM, John H. Reinhardt
<johnhreinhardt(a)thereinhardts.org> wrote:
...
I don't have Multinet anywhere (yet) so I will try the DDCMP via TCP. That seems the
most reasonable place to start.
Yes, though DDCMP over UDP also works well; it's become my default choice.
6:55 p.m.
On Aug 17, 2023, at 12:40 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2023-08-17 18:36, Paul Koning wrote:
Say what? Did you think something in reverse here, Paul?
I thought we had agreed that DDCMP over UDP is the worst idea. TCP makes total sense, but
UDP means you can get reordering, duplication and lost packets galore.
Or are you thinking of using something that addds the whole DDCMP protocol on top of UDP?
Doable. Maybe something in PyDECnet I have forgotten?
DDCMP in SIMH and in PyDECnet is the whole DDCMP data link protocol. It handles all those
things you mentioned, though just like any ARQ protocol the performance will drop a lot
if those problems occur at significant rates. BTW, UDP (or more precisely, IP) should not
normally duplicate packets, and reordering may be rare for many topologies.
Maybe you're thinking about an early "DDCMP data service" that was in SIMH,
and existed for a while in PyDECnet. That only works over TCP since it carries the
payload, not the DDCMP protocol messages (DLSDU rather than DLPDU, in
"Internationalbureaucratspeak" as Andrew Tanenbaum phrased it).
The "known very bad" choice is Multinet over UDP. And even Multinet over TCP is
iffy, though I admit that part of the reason I avoid it is on architectural purity
principles -- the people who designed Multinet clearly demonstrated their lack of
interest, or lack of ability, to understand the DECnet protocol specifications. So while,
with some care and feeding, it can be made to operate, it just is not and never can be
"correct".
paul
On Aug
17, 2023, at 12:25 PM, John H. Reinhardt <johnhreinhardt(a)thereinhardts.org> wrote:
...
I don't have Multinet anywhere (yet) so I will try the DDCMP via TCP. That seems the
most reasonable place to start.
Yes, though DDCMP over UDP also works well;
it's become my default choice.
7:03 p.m.
On 2023-08-17 18:55, Paul Koning wrote:
Ah. You were thinking of the full DDCMP over the link. Ok.
But yes, both lost, reordered and duplicated packets in IP are unusual,
but it can happen, for various reasons.
On Aug 17, 2023, at 12:40 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2023-08-17 18:36, Paul Koning wrote:
Say what? Did you think something in reverse here, Paul?
I thought we had agreed that DDCMP over UDP is the worst idea. TCP makes total sense, but
UDP means you can get reordering, duplication and lost packets galore.
Or are you thinking of using something that addds the whole DDCMP protocol on top of UDP?
Doable. Maybe something in PyDECnet I have forgotten?
DDCMP in SIMH and in PyDECnet is the whole DDCMP data link protocol. It handles all
those things you mentioned, though just like any ARQ protocol the performance will drop a
lot if those problems occur at significant rates. BTW, UDP (or more precisely, IP) should
not normally duplicate packets, and reordering may be rare for many topologies. On Aug
17, 2023, at 12:25 PM, John H. Reinhardt <johnhreinhardt(a)thereinhardts.org> wrote:
...
I don't have Multinet anywhere (yet) so I will try the DDCMP via TCP. That seems the
most reasonable place to start.
Yes, though DDCMP over UDP also works well;
it's become my default choice. Maybe you're thinking about an early "DDCMP
data service" that was in SIMH, and existed for a while in PyDECnet. That only works
over TCP since it carries the payload, not the DDCMP protocol messages (DLSDU rather than
DLPDU, in "Internationalbureaucratspeak" as Andrew Tanenbaum phrased it).
The "known very bad" choice is Multinet over UDP. And even Multinet over TCP
is iffy, though I admit that part of the reason I avoid it is on architectural purity
principles -- the people who designed Multinet clearly demonstrated their lack of
interest, or lack of ability, to understand the DECnet protocol specifications. So while,
with some care and feeding, it can be made to operate, it just is not and never can be
"correct".
I was more thinking of the latter. But it was probably a bit of mixum
from my side. Multinet pretends to be DDCMP, but don't actually do
DDCMP. Which is where things go bad.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
7:25 p.m.
I'm curious if I understand the suggestions correctly? If I was to have
connections from several DECnet capable machines on my home network
connecting to a PyDECnet/HECnet router hosted elsewhere with each one
configured to use DDCMP over the slower WAN/VPN link, then any local
machine to machine traffic would end up traversing the WAN link twice -
that is unless the home systems are configured with multiple circuits?
While I'm sure this is quite possible, I suspect it would be a more complex
configuration. Having a PyDECnet router on the home LAN and just using
standard ethernet circuits for DECnet would simplify the configuration for
all the local nodes. You could still have the choice of whether the HECnet
destined traffic is routed directly out over the dynamic IP of the home
circuit, or the fixed IP of the business circuit (via the VPN)?
Just some thoughts... :)
Cheers - Brian
On Thu, Aug 17, 2023 at 1:03 PM Johnny Billquist <bqt(a)softjar.se> wrote:
On 2023-08-17 18:55, Paul Koning wrote:
> On Aug 17, 2023, at 12:40 PM, Johnny Billquist <bqt(a)softjar.se> wrote:
>
> On 2023-08-17 18:36, Paul Koning wrote:
>>> On Aug 17, 2023, at 12:25 PM, John H. Reinhardt <
johnhreinhardt(a)thereinhardts.org> wrote:
>>>
>>> ...
>>>
>>> I don't have Multinet anywhere (yet) so I will try the DDCMP via TCP.
That seems the most reasonable place to start.
>> Yes, though DDCMP over UDP also works
well; it's become my default
choice.
>
> Say what? Did you think something in reverse here, Paul?
> I thought we had agreed that DDCMP over UDP is the worst idea. TCP
makes total
sense, but UDP means you can get reordering, duplication and
lost packets galore.
>
> Or are you thinking of using something that addds the whole DDCMP
protocol on
top of UDP? Doable. Maybe something in PyDECnet I have
forgotten?
DDCMP in SIMH and in PyDECnet is the whole DDCMP data link protocol. It
handles
all those things you mentioned, though just like any ARQ protocol
the performance will drop a lot if those problems occur at significant
rates. BTW, UDP (or more precisely, IP) should not normally duplicate
packets, and reordering may be rare for many topologies.
Ah. You were thinking of the full DDCMP over the link. Ok.
But yes, both lost, reordered and duplicated packets in IP are unusual,
but it can happen, for various reasons.
Maybe you're thinking about an early
"DDCMP data service" that was in
SIMH, and existed for a while in
PyDECnet. That only works over TCP since
it carries the payload, not the DDCMP protocol messages (DLSDU rather than
DLPDU, in "Internationalbureaucratspeak" as Andrew Tanenbaum phrased it).
The "known very bad" choice is Multinet over UDP. And even Multinet
over TCP is iffy, though I admit that part of the reason I avoid it is on
architectural purity principles -- the people who designed Multinet clearly
demonstrated their lack of interest, or lack of ability, to understand the
DECnet protocol specifications. So while, with some care and feeding, it
can be made to operate, it just is not and never can be "correct".
I was more thinking of the latter. But it was probably a bit of mixum
from my side. Multinet pretends to be DDCMP, but don't actually do
DDCMP. Which is where things go bad.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
7:36 p.m.
On Aug 17, 2023, at 1:25 PM, Brian Angus
<brian.angus(a)gmail.com> wrote:
I'm curious if I understand the suggestions correctly? If I was to have connections
from several DECnet capable machines on my home network connecting to a PyDECnet/HECnet
router hosted elsewhere with each one configured to use DDCMP over the slower WAN/VPN
link, then any local machine to machine traffic would end up traversing the WAN link twice
- that is unless the home systems are configured with multiple circuits? While I'm
sure this is quite possible, I suspect it would be a more complex configuration. Having a
PyDECnet router on the home LAN and just using standard ethernet circuits for DECnet would
simplify the configuration for all the local nodes. You could still have the choice of
whether the HECnet destined traffic is routed directly out over the dynamic IP of the home
circuit, or the fixed IP of the business circuit (via the VPN)? Just some thoughts...
:)
If you have several machines at home it certainly is efficient to have a home router,
which in turn connects to elsewhere over whatever connections you like. Connecting
multiple home machines to a remote router is fine if the link is reasonably fast, but as
you say you end up with extra distance and perhaps bottlenecks on slow links.
The nice thing about PyDECnet (or for that matter Rob Jarratt's user mode router) is
that it's just a bit of software that runs on any number of very cheap devices. I
have one instance on a BeagleBone Black, that's a router for less than $100.
paul
8:05 p.m.
Correct.
And I agree, why would you ever want to have your "central" router
located somewhere else, and have individual links from every machine to
there. Makes no sense.
Ethernet for the local network. One router (or maybe a couple) on the
local network that provides links to the rest of HECnet.
Johnny
On 2023-08-17 19:25, Brian Angus wrote:
I'm curious if I understand the suggestions
correctly? If I was to have
connections from several DECnet capable machines on my home network
connecting to a PyDECnet/HECnet router hosted elsewhere with each one
configured to use DDCMP over the slower WAN/VPN link, then any local
machine to machine traffic would end up traversing the WAN link twice -
that is unless the home systems are configured with multiple circuits?
While I'm sure this is quite possible, I suspect it would be a more
complex configuration. Having a PyDECnet router on the home LAN and
just using standard ethernet circuits for DECnet would simplify the
configuration for all the local nodes. You could still have the choice
of whether the HECnet destined traffic is routed directly out over the
dynamic IP of the home circuit, or the fixed IP of the business
circuit (via the VPN)? Just some thoughts... :)
Cheers - Brian
On Thu, Aug 17, 2023 at 1:03 PM Johnny Billquist <bqt(a)softjar.se
<mailto:bqt@softjar.se>> wrote:
On 2023-08-17 18:55, Paul Koning wrote:
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
> On Aug 17, 2023, at 12:40 PM, Johnny Billquist <bqt(a)softjar.se
<mailto:bqt@softjar.se>> wrote:
>
> On 2023-08-17 18:36, Paul Koning wrote:
>>> On Aug 17, 2023, at 12:25 PM, John H. Reinhardt
<johnhreinhardt(a)thereinhardts.org
<mailto:johnhreinhardt@thereinhardts.org>> wrote:
>>>
>>> ...
>>>
>>> I don't have Multinet anywhere (yet) so I will try the DDCMP
via TCP. That seems the most reasonable place to start.
>> Yes, though DDCMP over UDP also works
well; it's become my
default choice.
>
> Say what? Did you think something in reverse here, Paul?
> I thought we had agreed that DDCMP over UDP is the worst idea.
TCP makes
total sense, but UDP means you can get reordering,
duplication and lost packets galore.
>
> Or are you thinking of using something that addds the whole
DDCMP protocol
on top of UDP? Doable. Maybe something in PyDECnet I
have forgotten?
DDCMP in SIMH and in PyDECnet is the whole DDCMP data link
protocol. It
handles all those things you mentioned, though just
like any ARQ protocol the performance will drop a lot if those
problems occur at significant rates. BTW, UDP (or more precisely,
IP) should not normally duplicate packets, and reordering may be
rare for many topologies.
Ah. You were thinking of the full DDCMP over the link. Ok.
But yes, both lost, reordered and duplicated packets in IP are unusual,
but it can happen, for various reasons.
Maybe you're thinking about an early
"DDCMP data service" that
was in SIMH, and existed for a while in
PyDECnet. That only works
over TCP since it carries the payload, not the DDCMP protocol
messages (DLSDU rather than DLPDU, in "Internationalbureaucratspeak"
as Andrew Tanenbaum phrased it).
The "known very bad" choice is Multinet over UDP. And even
Multinet
over TCP is iffy, though I admit that part of the reason I
avoid it is on architectural purity principles -- the people who
designed Multinet clearly demonstrated their lack of interest, or
lack of ability, to understand the DECnet protocol specifications.
So while, with some care and feeding, it can be made to operate, it
just is not and never can be "correct".
I was more thinking of the latter. But it was probably a bit of mixum
from my side. Multinet pretends to be DDCMP, but don't actually do
DDCMP. Which is where things go bad.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se <mailto:bqt@softjar.se> ||
Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
<mailto:hecnet@lists.dfupdate.se>
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
<mailto:hecnet-leave@lists.dfupdate.se>
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
8:10 p.m.
F.Y.I: I've been running PyDECnet on a Raspberry Pi 3B+ for a couple of
years with no issues (about $35.00). I suspect it would work fairly well
on even older and slower model Pi's, but then again, I'm not stressing
anything with my usage levels.
Another quick point in favour of configuring one's DECnet nodes to use
simple Ethernet circuits and having a local router is that the local
network (both DECNET and IP) will be up and moderately happy even when the
WAN links and/or VPN server have other unfortunate challenges.
And yes, everyone here should have several DECnet nodes up and running...
Cheers
8:20 p.m.
On Aug 17, 2023, at 2:10 PM, Brian Angus
<brian.angus(a)gmail.com> wrote:
F.Y.I: I've been running PyDECnet on a Raspberry Pi 3B+ for a couple of years with no
issues (about $35.00). I suspect it would work fairly well on even older and slower model
Pi's, but then again, I'm not stressing anything with my usage levels.
Another quick point in favour of configuring one's DECnet nodes to use simple
Ethernet circuits and having a local router is that the local network (both DECNET and IP)
will be up and moderately happy even when the WAN links and/or VPN server have other
unfortunate challenges.
And yes, everyone here should have several DECnet nodes up and running...
Another reason to use a local router is to connect to "real nodes" -- as opposed
to emulated ones. Whether you need Ethernet or DDCMP connectivity, you can get that with
a PyDECnet router.
paul
6:37 p.m.
Just like Paul, I see no reason why VPN would cause any issues.
It's basically just tunneling the traffic through another layer to exit
somewhere else. There is nothing else to it.
(Speaking as one who was doing VPN development until a few months ago...)
Johnny
On 2023-08-17 18:25, John H. Reinhardt wrote:
On 8/17/2023 8:02 AM, Paul Koning wrote:
Thanks Johnny and Paul!
I do at least want to try the connection through the VPN. I'm curious if
it works as well. The VPN connection has been very reliable for TCP
traffic but it's not heavily loaded. I keep a "top" session running on
each system there just to see if/when it breaks. It has typicallygone
months without a problem other than when we have had extended power
outages or my local internet has gone down.
I don't have Multinet anywhere (yet) so I will try the DDCMP via TCP.
That seems the most reasonable place to start.
John H. Reinhardt
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Aug 16, 2023, at 11:21 PM, John H. Reinhardt
<johnhreinhardt(a)thereinhardts.org> wrote:
So Mark (Matlock) has been after me to get my HECnet connection up
and running and me, being an ace procrastinator, has always said
"Real Soon Now™", Mark.
I might actually have time to do it as I'm on vacation for a week and
a half. Despite the heat I could set something up. My question is
how do I set it up. I have a Mac Mini in Las Vegas running VMWare
ESXi. I have a VM (Aniketos) running Vyos for a firewall/router,
another VM with an Nginx web server (Hermes - irrelevant just
mentioned for completeness) and a really small (1 vCPU) Linux VM
(Knight) which I want to run Paul's PyDECnet router for the world to
connect to. From there I have an IPSec VPN to my Ubiquiti EdgeRouter
4 at home. How can I connect DECnet through the VPN to Knight from
home? Is it even possible? Do I need or want GRE tunnels through
the VPN?
Am I just making it too complicated and should I set up a PyDECnet
router at home and go that way through my dynamic IP? It's possible I
could set up an x86 OpenVMS machine as another VM
I'm thinking I need a PyDECnet router at home to collect all the
DECnet traffic and shove it through the VPN to the PyDECnet router at
the remote site and from there out into the internet to it's HECnet
connection points. Does that make sense?
A router at home that uses the dynamic
IP address is certainly a valid
option, one a bunch of us use today.
I don't know that anyone has tried running a DECnet circuit through an
IPSec VPN, but clearly it should work. You'd just point the DECnet
circuit to the IP address of the other end of the tunnel, with the
local address of the circuit set to the local endpoint of the tunnel.
Then you can use any IP based communication method that is enabled by
the filter rules of the VPN. For example, if the VPN allows any IP
traffic, you could use anything IP based, from GRE to Multinet to
DDCMP. If you want to be more restrictive, you could enable justthe
one protocol and port you want. For example, that could be TCP on
which you run Multinet, or TCP or UPD carrying DDCMP.
If you do go this VPN route it would be interesting to hear how it
works for you, especially if you run into problems.
paul
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se 
8:29 p.m.
I have been doing IPsec based VPN's since about 1995, some of it being
on Cisco (2600's), much of it being on consumer units, so this isn't a
completely informed, definitive opinion.
From the programmatic standpoint, there is nothing that I am aware of
in either the socket interface on Windows or Unix or in the BBC JCN or
DEC JSYS Interface on Tops-20 that you could query that would
definitively tell you that you are going over a VPN. I don't believe
there is anything in z/OS (née MVS) or z/TPF (née TPF), either, but I do
not have direct programming experience there.
The VPN router hides that encapsulation and routing, which is what keeps
sensitive applications like H.323 and FTP from not working. That being
said, you could certainly inspect the IP subnet and make a reasonable
guess that, if you are on a 10/24, 192.168/16 or 172/24 subnet, you are
on a NAT'ing router, which is typically what is used for a VPN. Of
course, there are many, many NAT'ed networks, so this is no guarantee of
anything.
Another way to guess would be by looking at packet paths and timing, but
that assumes you have knowledge of the network topology.
So not only should it work, it should work understandably for any DECnet
application, probably NICE, too.
On 8/17/23 12:37 PM, Johnny Billquist wrote:
Just like Paul, I see no reason why VPN would cause
any issues.
It's basically just tunneling the traffic through another layer to
exit somewhere else. There is nothing else to it.
(Speaking as one who was doing VPN development until a few months ago...)
Johnny
On 2023-08-17 18:25, John H. Reinhardt wrote:
On 8/17/2023 8:02 AM, Paul Koning wrote:
Thanks Johnny and Paul!
I do at least want to try the connection through the VPN. I'm curious
if it works as well. The VPN connection has been very reliable for
TCP traffic but it's not heavily loaded. I keep a "top" session
running on each system there just to see if/when it breaks. It has
typicallygone months without a problem other than when we have had
extended power outages or my local internet has gone down.
I don't have Multinet anywhere (yet) so I will try the DDCMP via TCP.
That seems the most reasonable place to start.
John H. Reinhardt
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
On Aug 16, 2023, at 11:21 PM, John H. Reinhardt
<johnhreinhardt(a)thereinhardts.org> wrote:
So Mark (Matlock) has been after me to get my HECnet connection up
and running and me, being an ace procrastinator, has always said
"Real Soon Now™", Mark.
I might actually have time to do it as I'm on vacation for a week
and a half. Despite the heat I could set something up. My
question is how do I set it up. I have a Mac Mini in Las Vegas
running VMWare ESXi. I have a VM (Aniketos) running Vyos for a
firewall/router, another VM with an Nginx web server (Hermes -
irrelevant just mentioned for completeness) and a really small (1
vCPU) Linux VM (Knight) which I want to run Paul's PyDECnet router
for the world to connect to. From there I have an IPSec VPN to my
Ubiquiti EdgeRouter 4 at home. How can I connect DECnet through
the VPN to Knight from home? Is it even possible? Do I need or
want GRE tunnels through the VPN?
Am I just making it too complicated and should I set up a PyDECnet
router at home and go that way through my dynamic IP? It's possible
I could set up an x86 OpenVMS machine as another VM
I'm thinking I need a PyDECnet router at home to collect all the
DECnet traffic and shove it through the VPN to the PyDECnet router
at the remote site and from there out into the internet to it's
HECnet connection points. Does that make sense?
A router at home that uses the
dynamic IP address is certainly a
valid option, one a bunch of us use today.
I don't know that anyone has tried running a DECnet circuit through
an IPSec VPN, but clearly it should work. You'd just point the
DECnet circuit to the IP address of the other end of the tunnel,
with the local address of the circuit set to the local endpoint of
the tunnel. Then you can use any IP based communication method that
is enabled by the filter rules of the VPN. For example, if the VPN
allows any IP traffic, you could use anything IP based, from GRE to
Multinet to DDCMP. If you want to be more restrictive, you could
enable justthe one protocol and port you want. For example, that
could be TCP on which you run Multinet, or TCP or UPD carrying DDCMP.
If you do go this VPN route it would be interesting to hear how it
works for you, especially if you run into problems.
paul
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se 
463
days inactive
463
days old
16 comments
6 participants
participants (6)
-
Brian Angus -
Iain Hardcastle -
John H. Reinhardt -
Johnny Billquist -
Paul Koning -
Thomas DeBellis