Not sure about this, but from the 'bottom' network, you are trying to access a webserver that gets it's IP address from itself as you have Hostapd and dnsmasq running on the machine. So does the VPN server not know the address of the Webserver as this address has been obtained by DHCP?
But if you go by VPN link into another device which is on the 'public' side this device does know the Webserver (fixed) address. Peter On 16/04/2022 13:09, Terry Coles wrote:
Hi, Sorry to raise this again but *some* progress has been made with the access issues that I've been having at the WMT. There is a diagram showing the physical arrangement of the devices on site (and in my local test rig) at: https://hadrian-way.co.uk/Misc/Network_Configuration.png[1] As well as the Webserver, the Pi at 192.168.0.1 includes a DNS Server (created using dnsmasq). This serves up the hostnames of all the devices on the WMT Network. Here is a synopsis of 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 via the on site Antennas. * 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 VPN Network via VPN unless an intermediate device is used as a 'stepping stone'. (eg, log into another Pi and then log in to the Webserver from there. * The DNS Server does not work for clients logged into the VPN Network via VPN. 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. 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. If I query iptables, the routing seems to be there: sudo iptables -L [sudo] password for vuser: Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT all -- 10.1.10.0/24 192.168.0.0/24 policy match dir in pol ipsec reqid 1 proto esp ACCEPT all -- 192.168.0.0/24 10.1.10.0/24 policy match dir out pol ipsec reqid 1 proto esp ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination If from my client PC with VPN Active I do the command: *terry@OptiPlex*:*~/Useful*$ systemd-resolve --status *Global* Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: foreign *Link 2 (eno1)* Current Scopes: DNS Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 192.168.1.1 DNS Servers: 192.168.1.1 I can't see the DNS Server on 192.168.0.1: This problem isn't the end of the world; it's just plain inconvenient. If anyone can see anything that I should check (or better still the deliberate error in the system), I'd be extremely grateful.
-- Next meeting: Online, Jitsi, Tuesday, 2022-05-03 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk