Winter Shutdown and Aspirations for the Future

[Penri]

Received the following comments from Greg yesterday, along with thanks for your speedy work:

Tried the guide this morning and my phone, although finding the WMT Guest opening screen could not go further, but fine this afternoon. It looks good, no comment on the voice. I hope Mandy will be able to print out and fix new signage that I will forward to her.

For reference Greg has a Samsung S9 running Android 10.

Thought it worth logging.

[TerryJC]

Sitrep on Access Issues Via VPN

Since I last posted on this issue I've had a number of email exchanges with the author of Pistrong (strongSwan installer script for the VPN Server) in the hope that his superior networking knowledge might help. Here is the current situation:

• The Webserver content is accessible to Visitors on site without any reported issues to date. This means that Nodogsplash is doing what it should do.
• The Webserver (and all other networked devices) may be accessed from a laptop logged into the WMT Network on site. (see Notes below.)
• The DNS Server works properly for all devices logged into the WMT Network from the site.
• The Webserver is inaccessible to clients logged into the WMT Network via VPN unless an intermediate device is used as a 'stepping stone'. (eg, log into Sump Pi and then log in to the Webserver from there.
• The DNS Server does not work for clients logged into the WMT Network via VPN.

Notes:

1. The inability to access the DNS Server from my laptop that I reported on the 7th was due to some idiosyncrasy of the on-board WiFi Adaptor. When I plugged in a TP-Link USB/WiFi Adaptor and logged on to the WMT Antenna using that, the DNS functionality was OK.
2. Since then I have had multiple conversations with the author of Pistrong. Despite numerous suggestions, nothing seems to work in respect to getting direct access to the Webserver or the DNS Server remotely.

I will have one last attempt to get to the bottom of this through the Linux User Group. There has been one new thing discovered; there doesn't seem to be a route between the VPN Server and the Webserver. It seems to me that would account for the behaviour I'm seeing but I can't see why the routing isn't working at the moment.

[hamishmb]

Hmm, curious.

So when SSHing into the VPN Server as a stepping stone, we can't ping or SSH into the Webserver? That would confirm that there is no route. Why there wouldn't be a route, I don't know, but the output of

Code: Select all

route -n

when run on the VPN Server might be useful.

[TerryJC]

So when SSHing into the VPN Server as a stepping stone, we can't ping or SSH into the Webserver? That would confirm that there is no route. Why there wouldn't be a route, I don't know, but the output of

Code: Select all

route -n

when run on the VPN Server might be useful.

Actually, you can ssh into the Webserver from the VPN Server, but not ping it!!!

Code: Select all

vuser@VPN-Server:~ $ ssh [email protected]
[email protected]'s password: 
Linux WMT-Webserver 5.10.103-v7+ #1529 SMP Tue Mar 8 12:21:37 GMT 2022 armv7l
....
Last login: Fri Apr  8 15:31:26 2022 from 192.168.0.2
wuser@WMT-Webserver:~ $ exit
logout
Connection to 192.168.0.1 closed.
vuser@VPN-Server:~ $ ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
From 192.168.0.1 icmp_seq=1 Destination Port Unreachable

vuser@VPN-Server:~ $ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    204    0        0 eth1
192.168.0.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     204    0        0 eth1

Does that offer any clues?

[hamishmb]

I will read up on Linux routing and networking stuff again and get back to you, but I think we have a lead here.

What about "route -n" from the VPN server, and from the Webserver (might as well do that too)

[hamishmb]

Also, does the reverse work (pinging the VPN server from the webserver)?

[hamishmb]

NB: Destination Port Unreachable suggests that a firewall on the webserver is blocking the ICMP packets used by ping. I will verify this shortly.

[TerryJC]

Hamish,

The output of route -n from the VPN Server was included in the listing above.

I'll do the same from the Webserver and post back shortly.

[TerryJC]

It looks remarkably similar to the output from the VPN Server:

Code: Select all

wuser@WMT-Webserver:~ $ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    203    0        0 eth1
192.168.0.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     203    0        0 eth1

[hamishmb]

That looks fine, as long as the interface names are right and haven't been swapped somehow.

One thought: why are we using eth* names, instead of the more stable enx******** names that are guaranteed to not change between reboots or hardware changes? Using those in the future might make this easier.

My understanding is that the new-style enx******** names were the default on Raspberry Pi OS nowadays.