The problem is that some university machines are unknown to that gateway, so whenever I connect to the VPN, I lose access to certain systems. This also happens, for example, with the Anydesk network.

I ended up using the following lines of code to fix the routing. In this setup:

• 192.168.16.10 is the Forticlient VPN server,
• 84.17.62.0 is the Anydesk network (you’ll need to identify this yourself before modifying routes),
• 192.168.151.27 is the IP of my DGX system.

# deletes the default forticlient route "ALL GOES TO FORTICLIENT"
sudo route del -net 0.0.0.0 netmask 0.0.0.0 gw 192.168.16.10 dev ppp0 metric 0

# routes 84.17.62.0 which is the network of anydesk to the wired interface directly
sudo route add -net 84.17.62.0 netmask 255.255.255.0 metric 0 dev enx1ce192ff37f8 gw 192.168.67.254

# add a route to the dgx ip address through the forticlient interface (ppp0)
sudo route add -net 192.168.151.27 netmask 255.255.255.255 metric 0 dev ppp0 gw 192.168.16.10

Hope that’s helpful :-)

Augusto

:-)

You can find our preprint here

Title: Model Guided Road Intersection Classification

Abstract: Understanding complex scenarios from in-vehicle cameras is essential for safely operating autonomous driving systems in densely populated areas. Among these, intersection areas are one of the most critical as they concentrate a considerable number of traffic accidents and fatalities. Detecting and understanding the scene configuration of these usually crowded areas is then of extreme importance for both autonomous vehicles and modern ADAS aimed at preventing road crashes and increasing the safety of vulnerable road users. This work investigates inter-section classification from RGB images using well-consolidate neural network approaches along with a method to enhance the results based on the teacher/student training paradigm. An extensive experimental activity aimed at identifying the best input configuration and evaluating different network parameters on both the well-known KITTI dataset and the new KITTI-360 sequences shows that our method outperforms current state-of-the-art approaches on a per-frame basis and prove the effectiveness of the proposed learning scheme.

• the so-called “security by obscurity” or “security through obscurity” practice of change default service ports
• adding multiple layers of supposed security instead of rely on one secure protocol

Regarding the first one, I will try to contact my old “Computer Security” professor of the M.Sc. course to give some more details. In the meanwhile, you can read the Wikipedia page or just use a web serach engine.

Port forwarding

You can have a look of what a tunnel is in the official ssh page.

Suppose you have a REMOTE_MACHINE_A you want to login or use or whatever, but that machine is in a remote network you can not access. But, you have accesso to REMOTE_MACHINE_B behind a firewall with only the port XXX open. What you can do is setup a tunne through the servers, consisting in successive jumps that will allow you to enter to the REMOTE_MACHINE_A like a charm.

What you have to do are just two “local” tunnels.

On your machine, the one you are working, create a local tunnel to the machine where you have access. The ports at this moment are not important, let add use a “port shift” of 10000 (or 10100) method to denote that if we want to use port 22 of the final machine, now we’ll use 10022 or 10122. Last thing, localhost is the same as 127.0.0.1 ;-).

Create tunnel from port localhost port 10022 to REMOTE_MACHINE_B port 10122. Use USER@REMOTE_MACHINE_B to access the remote machine. In this way, every local connection to port 10022 will be forwarded to port 10122 on the remote machine, automagically, encrypted.

1. ssh -L 10022:localhost:10122 USER@REMOTE_MACHINE_B

In this way, if you have a service listening to port 10122 on the REMOTE machine BUT that port is hidden with a firewall, now on your LOCAL machine machine you can log to the LOCAL machine on port 10022 without saying anything about the REMOTE machine, the tunnel will do the grunt work.

Iterating this procedure you can add more “jumps” too. Example: want to connect to the port 22 of REMOTE_MACHINE_A?

1. LOCAL MACHINE: ssh -L 10022:localhost:10122 USER@REMOTE_MACHINE_B
2. MACHINE-B:     ssh -L 10122:localhost:22 USER@REMOTE_MACHINE_A

then, access to the local machine BUT to the port we specified in the first tunnel and ssh will forward the request through REMOTE_MACHINE_B directly to REMOTE_MACHINE_A, even though for your ssh agent you’re connecting to the LOCAL port.

3. LOCAL MACHINE: ssh user@localhost -p 10022

that’s all folks.