Re: [Dorset] Wimborne Model Town Routing Problem
On Tue, 19 Apr 2022 09:45:02 +0100, Hamish McIntyre-Bhatty wrote: > On 19/04/2022 07:27, Terry Coles wrote: > > On Monday, 18 April 2022 20:26:36 BST Patrick Wigmore wrote: > >> If there isn't a suitable route to 192.168.0.0/24 on the VPN > >> client > >> computer, then manually adding one temporarily might be a > >> worthwhile experiment. > >> > >> Hmmm. I've been struggling to find the correct iptables command > >> to do that. > Note: iptables is a firewall, and doesn't handle routing. > > You probably need to add a route with "route add" but I don't know > what options to use after that. The only one I have used is "route > add default gw x.x.x.x" so I will let Patrick handle this - he > knows more Linux-specific stuff than I do here. I would use ip route add, but I am not really 'up' on the specifics. It is something I would figure out by trial and error (and reading the manual). But I forgot that IPSec VPNs don't present themselves as virtual network interfaces, which means it isn't necessarily obvious when you have a route that's going through the VPN, and I am not sure whether it is actually possible to create a route manually in the way I was thinking. I was imagining that you would see a route to [something] via [a VPN network interface], as you would with some other types of VPN. But instead, you'll see something like a route to [something] via [the same network interface that handles your default route] and via [the VPN server], with the kernel knowing (somehow - I forget exactly how) that it needs to encrypt packets that take that route. Looking at your ip route show output > terry@OptiPlex:~/Useful$ ip route show > default via 192.168.1.1 dev eno1 proto dhcp metric 100 > 169.254.0.0/16 dev eno1 scope link metric 1000 > 192.168.1.0/24 dev eno1 proto kernel scope link src 192.168.1.21 > metric 100 I think that last line is probably the route through the VPN, though I am not entirely certain. I've forgotten most of what I previously learnt about how routing works with IPSec. Sorry for being a bit vague. This is more of a heads up that I may have sent you on a wild goose chase than an attempt to unpick it properly. Patrick -- 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
Re: [Dorset] Wimborne Model Town Routing Problem
On 19/04/2022 07:27, Terry Coles wrote: On Monday, 18 April 2022 20:26:36 BST Patrick Wigmore wrote: If there isn't a suitable route to 192.168.0.0/24 on the VPN client computer, then manually adding one temporarily might be a worthwhile experiment. Hmmm. I've been struggling to find the correct iptables command to do that. Should this be a direct route from 10.1.10.1 to 192.168.0.1 or 192.168.0.30 to 192.168.0.1. Also should the protocol be NAT? Whatever I've tried so far doesn't seem to show up when I list the current rules, so I've been unable to confirm or deny that this was the problem. It seems you've got me hooked on this puzzle, Terry. I was only going to write a few paragraphs here, to clarify my previous remarks! Sorry about that. :-) Note: iptables is a firewall, and doesn't handle routing. You probably need to add a route with "route add" but I don't know what options to use after that. The only one I have used is "route add default gw x.x.x.x" so I will let Patrick handle this - he knows more Linux-specific stuff than I do here. Hamish -- 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
Re: [Dorset] Wimborne Model Town Routing Problem
On Monday, 18 April 2022 20:26:36 BST Patrick Wigmore wrote: > If there isn't a suitable route to 192.168.0.0/24 on the VPN client > computer, then manually adding one temporarily might be a worthwhile > experiment. Hmmm. I've been struggling to find the correct iptables command to do that. Should this be a direct route from 10.1.10.1 to 192.168.0.1 or 192.168.0.30 to 192.168.0.1. Also should the protocol be NAT? Whatever I've tried so far doesn't seem to show up when I list the current rules, so I've been unable to confirm or deny that this was the problem. > It seems you've got me hooked on this puzzle, Terry. I was only going > to write a few paragraphs here, to clarify my previous remarks! Sorry about that. :-) -- Terry Coles -- 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
Re: [Dorset] Wimborne Model Town Routing Problem
On Monday, 18 April 2022 20:26:36 BST Patrick Wigmore wrote: > I suppose one thing to check is whether, while connected to the VPN, > you have any other (conflicting) routes to 192.168.0.0/24. Or, indeed, > whether there is a route to 192.168.0.0/24 at all. E.g. run > > $ ip route show > > on your VPN client computer and see where it thinks it should send > traffic destined for 192.168.0.0/24. Here it is: terry@OptiPlex:~/Useful$ ip route show default via 192.168.1.1 dev eno1 proto dhcp metric 100 169.254.0.0/16 dev eno1 scope link metric 1000 192.168.1.0/24 dev eno1 proto kernel scope link src 192.168.1.21 metric 100 -- Terry Coles -- 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
Re: [Dorset] Wimborne Model Town Routing Problem
On 18/04/2022 20:26, Patrick Wigmore wrote: On Mon, 18 Apr 2022 10:23:19 +0100, Terry Coles wrote: When a VPN client connects to the Web Server, in theory the web server would see that connection coming in from a 10.1.10.0/24 address, not a 192.168.0.0/24 one. So, it is a given that the Webserver has to be configured to accept connections from 10.1.10.0/24 clients. So how would I do that? I always assumed that the VPN Server included a router that would sort all that out. The iptables output would indicate that it does. I suppose there is some nuance here; the connection would come from a 10.1.10.0/24 address, routed via the 192.168.0.0/24 address of the VPN server. So, the Webserver would see that 192.168.0. had forwarded it some traffic that originated from 10.1.10.x. If the VPN server were doing NAT routing/masquerading, as opposed to plain old routing, then the connection would appear to come directly from the VPN server's 192.168.0.0/24 address. I suppose the VPN server *could* be doing NAT routing, but that would be a little surprising to me, because I am not seeing how NAT routing would be beneficial in this set-up. But I only mentioned this in case you had configured the server to block connections that weren't from 192.168.0.0/24 addresses, so if you haven't done that then I can't see it being a concern. The only other thing that comes to mind on a brief reading of your response to me is that, if the web server isn't accessible by IP address, then it certainly isn't going to be accessible via hostname. So, as you say, the routing falls under suspicion. The finer points of iptables configuration are perhaps a bit lost on me, so while I can look at the broad-strokes of your config, and I think it seems OK, I could easily be missing some nuances that might send it off the rails. I suppose one thing to check is whether, while connected to the VPN, you have any other (conflicting) routes to 192.168.0.0/24. Or, indeed, whether there is a route to 192.168.0.0/24 at all. E.g. run $ ip route show on your VPN client computer and see where it thinks it should send traffic destined for 192.168.0.0/24. That raises the question of how the VPN client learns which networks it can route to via the VPN. Presumably it does learn something, since you can access the various non-Webserver devices in the 192.168.0.0/24 network. Unless that's happening by fluke. If there isn't a suitable route to 192.168.0.0/24 on the VPN client computer, then manually adding one temporarily might be a worthwhile experiment. It seems you've got me hooked on this puzzle, Terry. I was only going to write a few paragraphs here, to clarify my previous remarks! Patrick Note: The VPN Server does not do NAT, as is evidenced by the "Last login from 10.1.10.x" prompt that I get after SSHing into one of the pis periodically. Hamish -- 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
Re: [Dorset] Wimborne Model Town Routing Problem
On Mon, 18 Apr 2022 10:23:19 +0100, Terry Coles wrote: > > When a VPN client connects to the Web Server, in theory the web > > server would see that connection coming in from a 10.1.10.0/24 > > address, not a 192.168.0.0/24 one. So, it is a given that the > > Webserver has to be configured to accept connections from > > 10.1.10.0/24 clients. > So how would I do that? I always assumed that the VPN Server > included a router that would sort all that out. The iptables > output would indicate that it does. I suppose there is some nuance here; the connection would come from a 10.1.10.0/24 address, routed via the 192.168.0.0/24 address of the VPN server. So, the Webserver would see that 192.168.0. had forwarded it some traffic that originated from 10.1.10.x. If the VPN server were doing NAT routing/masquerading, as opposed to plain old routing, then the connection would appear to come directly from the VPN server's 192.168.0.0/24 address. I suppose the VPN server *could* be doing NAT routing, but that would be a little surprising to me, because I am not seeing how NAT routing would be beneficial in this set-up. But I only mentioned this in case you had configured the server to block connections that weren't from 192.168.0.0/24 addresses, so if you haven't done that then I can't see it being a concern. The only other thing that comes to mind on a brief reading of your response to me is that, if the web server isn't accessible by IP address, then it certainly isn't going to be accessible via hostname. So, as you say, the routing falls under suspicion. The finer points of iptables configuration are perhaps a bit lost on me, so while I can look at the broad-strokes of your config, and I think it seems OK, I could easily be missing some nuances that might send it off the rails. I suppose one thing to check is whether, while connected to the VPN, you have any other (conflicting) routes to 192.168.0.0/24. Or, indeed, whether there is a route to 192.168.0.0/24 at all. E.g. run $ ip route show on your VPN client computer and see where it thinks it should send traffic destined for 192.168.0.0/24. That raises the question of how the VPN client learns which networks it can route to via the VPN. Presumably it does learn something, since you can access the various non-Webserver devices in the 192.168.0.0/24 network. Unless that's happening by fluke. If there isn't a suitable route to 192.168.0.0/24 on the VPN client computer, then manually adding one temporarily might be a worthwhile experiment. It seems you've got me hooked on this puzzle, Terry. I was only going to write a few paragraphs here, to clarify my previous remarks! Patrick -- 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
Re: [Dorset] Wimborne Model Town Routing Problem
Patrick, Thanks for your extremely detailed response; it's taken me a while to get through it and I hope that I've understood what you are saying properly. BTW. I've learned quite a bit :-) See my responses below. On Sunday, 17 April 2022 15:17:04 BST Patrick Wigmore wrote: > If I understand you correctly, I think you are saying that each device > on the WMT Network is allocated an address in the 10.1.10.0/24 range. > This does not make sense. Why would the WMT Network devices need > 10.1.10.0/24 addresses, in addition to their 192.168.0.0/24 ones? I'm not sure where the information came from regarding the 10.1.10.0/24 address range; probably in one of my many conversations with the author of pistrong. It looks like I misunderstood him. > This also means that the VPN clients will not be getting told about > the 192.168.0.1 DNS server via DHCP, so they won't automatically use > it. This means their traffic won't get forwarded to the web server > automatically. If you wanted them to know about that DNS server, you > would need to configure the VPN server to tell them about it. They > won't discover it automatically via DHCP like an on-site network > client would. According to the author of pistrong they are. Here is a part of the Query/ Response session that pistrong generates during installation and configuration of the server: DNS Server for connected VPN clients: 192.168.0.1,8.8.8.8 The bit before the : is the Query and the rest is my response. You can see that the system has the information and should provide it to the client during negotiation. However, there appears to be no path to 192.168.0.1 from the client in use and so (I assume) the client drops it and only 8.8.8.8 remains. (However see below.) Early in the development process the author of pistrong suggested that I add the 8.8.8.8 to that response so that the client could still access the Internet while connected to the WMT Network via the VPN Server. > Be aware that VPN clients will sometimes use a VPN-provided DNS server > for EVERYTHING, which could have the effect of intercepting DNS > queries for traffic that has nothing to do with the VPN, which might > break networking for things that are running on the same machine as > the VPN client, and could cause a privacy issue. If possible, it may > be better to configure the VPN clients so that the WMT DNS server is > only used to query domain names that are part of the WMT network. The WMT DNS Server does only provide IP Addresses for the hosts on the WMT Network. Putting together your comment about privacy and my old IT Manager's reaction when someone at work 'bridged' the network, I see that this wasn't a particularly good idea. > So, when you said: > > The VPN Server doesn't know the IP Address of the > > Webserver, but it doesn't need to because all traffic should be > > forwarded to it. > > The second part of the statement was untrue. The VPN server DOES need > to know the IP address of the Webserver (assuming you want it to tell > its clients), because the automatic forwarding to the Webserver only > works for DHCP clients in the local network. I think there may be a misconception here. When I said forwarding, I meant that any queries in the 192.168.0.0/21 subnet should be forwarded to all the devices in that subnet. That would include the Webserver on 192.168.0.1. However for that to happen the VPN Client clearly needs to know that that IP Address provides a DNS Server and for some reason it either doesn't or it does and it can't get there (see below) > Do you mean that it does not work automatically, or do you mean that > clients logged in via the VPN cannot query this server at all. What > happens if you say explicitly which server to query, by doing: > > $ dig @192.168.0.1 [webserver domain name] > > or > > $ nslookup [webserver domain name] 192.168.0.1 > > on a device that is connected via the VPN? This is where I took one or two steps forward. Below is the console output during a VPN session. I've interspersed a few comments: 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 This is the response immediately after I've connected from the client (my desktop machine). The client only knows about my local router which provides the DNS Service for machines logging on to my home network. I then logged on to VPN Server (I've obfuscated the username for security purposes because this is a public forum): terry@OptiPlex:~/Useful$ ssh @192.168.0.30 @192.168.0.30's password: Linux VPN-Server 5.15.32-v7l+ #1538 SMP Thu Mar 31 19:39:41 BST 2022 armv7l I then tried to run 'systemd-resolve --status' but this isn't supported so I did: *
Re: [Dorset] Wimborne Model Town Routing Problem
On Sun, 17 Apr 2022 08:32:23 +0100, Terry Coles wrote: > 10.1.10.0/24 is the network set up by > the VPN Server to forward remote traffic on and each device on the > WMT Network is allocated an address in that range If I understand you correctly, I think you are saying that each device on the WMT Network is allocated an address in the 10.1.10.0/24 range. This does not make sense. Why would the WMT Network devices need 10.1.10.0/24 addresses, in addition to their 192.168.0.0/24 ones? More likely, the 10.1.10.0/24 range is only used for the VPN server and the VPN clients, and VPN clients can simply address WMT Network devices directly, using their 192.168.0.0/24 addresses. As you've shown, the VPN server is configured to route between these subnets, so that should be fine and dandy. This is how I remember the VPN working before. This works in the same way that you can communicate to, say, a Google server in the range 216.58.192.0/19 from a computer that has a local IP address in the range 192.168.1.0/24. Clearly, Google's servers do not get renumbered to suit your local network. Neither are the WMT Network devices going to be renumbered to suit the VPN. It is not necessary or useful. The VPN clients are having their IP addresses allocated by the VPN server. I think it uses the VPN's own protocol as opposed to DHCP to communicate these addresses to the clients, but I can't remember for sure. Either way, the VPN server is responsible. This also means that the VPN clients will not be getting told about the 192.168.0.1 DNS server via DHCP, so they won't automatically use it. This means their traffic won't get forwarded to the web server automatically. If you wanted them to know about that DNS server, you would need to configure the VPN server to tell them about it. They won't discover it automatically via DHCP like an on-site network client would. Be aware that VPN clients will sometimes use a VPN-provided DNS server for EVERYTHING, which could have the effect of intercepting DNS queries for traffic that has nothing to do with the VPN, which might break networking for things that are running on the same machine as the VPN client, and could cause a privacy issue. If possible, it may be better to configure the VPN clients so that the WMT DNS server is only used to query domain names that are part of the WMT network. So, when you said: > The VPN Server doesn't know the IP Address of the > Webserver, but it doesn't need to because all traffic should be > forwarded to it. The second part of the statement was untrue. The VPN server DOES need to know the IP address of the Webserver (assuming you want it to tell its clients), because the automatic forwarding to the Webserver only works for DHCP clients in the local network. It is safe to assume that on-site Visitors devices, connecting via WiFi, are all configured to use DHCP, both to obtain an IP address and to learn about a DNS server. It is not safe to assume the same for VPN clients. Not only have the VPN clients already got an IP address from the VPN server, so they won't be looking for another one, but DHCP works using broadcast messages, which are only received by devices in the same subnet. So, given that they have 10.1.10.0/24 addresses, the VPN clients cannot make use of the 192.168.0.1 DHCP server. They should, however, be able to make use of the 192.168.0.1 *DNS* server, provided that they are told about it. > The DNS Server does not work for clients logged into the VPN Network > via VPN. Do you mean that it does not work automatically, or do you mean that clients logged in via the VPN cannot query this server at all. What happens if you say explicitly which server to query, by doing: $ dig @192.168.0.1 [webserver domain name] or $ nslookup [webserver domain name] 192.168.0.1 on a device that is connected via the VPN? > 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. Based on all of the above, I would expect that VPN clients cannot access the Webserver using its domain name, but they can do using its IP address. Is this true, or is it inaccessible even by IP address? If the Webserver is inaccessible even by IP address, what happens if you try to ping it? When a VPN client connects to the Web Server, in theory the web server would see that connection coming in from a 10.1.10.0/24 address, not a 192.168.0.0/24 one. So, it is a given that the Webserver has to be configured to accept connections from 10.1.10.0/24 clients. With that all said, that is far from the only way to configure IP addressing on an IPSec VPN. I'm relying on the fact I've used the WMT VPN in the past to fill in some of the blanks, and it is possible things could have moved on from that. (Or I could have misremembered.) Anyone coming across this thre
Re: [Dorset] Wimborne Model Town Routing Problem
On Saturday, 16 April 2022 21:47:06 BST Peter Merchant via dorset wrote: > 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? All of the devices on the WMT Network have static IP Addresses apart from the Visitors phones, etc. The VPN Server doesn't know the IP Address of the Webserver, but it doesn't need to because all traffic should be forwarded to it. In my original message there are some lines line from iptables: 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 Unless I've misunderstood this output everything to and from 10.1.10.0/24 should go to and from 192.168.0.0/24. 10.1.10.0/24 is the network set up by the VPN Server to forward remote traffic on and each device on the WMT Network is allocated an address in that range (including the VPN Server of course. Similarly 192.168.0.0/24 includes the Webserver's address, so I am very confused as to why remote traffic isn't being forwarded. I'm not an expert on iptables, but that's how I read it. -- 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
Re: [Dorset] Wimborne Model Town Routing Problem
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
[Dorset] Wimborne Model Town Routing Problem
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. -- Terry Coles [1] https://hadrian-way.co.uk/Misc/Network_Configuration.png -- 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
