17 Aug
2023
17 Aug
'23
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