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

Reply via email to