![]() Now the packet can be routed toward the central VPN server by adding a route on 192.168.0.10: ip route add 192.168.10.0/24 dev wg This would require a better than average off-the-shelf home router to provide this. or by configuring router's DHCP with DHCP option 121 + (non standard but it's Microsoft.) DHCP option 249.Optional but recommended if possible, add the same route on all systems in the LAN (to avoid sub-optimal ICMP redirects): The Linux command for this would have been: ip route add 192.168.10.0/24 via 192.168.0.10 dev eth0 OP can and must add again a static route on the router:Īdd on the router the route to 192.168.10.0/24 with 192.168.0.10 as gateway. or doesn't: packet is routed to the ISP and dropped or lost sooner or later somewhere on Internet: which is what would happen without changes.Īs OP wrote there is already an added static route defined for 10.11.12.0/24 on the router, it's possible to do so.either has the route to 192.168.10.20 via 192.168.0.10 and sends ICMP redirects to 192.168.0.20 to tell it to use the correct gateway for this destination (and cache it), while carrying on with the received first packets and still forwarding them.or doesn't have the route and sends it to 192.168.0.1, which.either has the route to it via 192.168.0.10 and sends packets through this gateway. ![]() It would hinder connectivity.Įnsuring the packet reaches next hop at each step Origin LAN Unless told otherwise, NAT doesn't have to be used below on a (VPN) network totally controlled by OP. These changes to routes and WireGuard configuration should be replicated likewise multiple times (total 2 remote lans x 3 lans = 6) to account for two other LANs to reach from each of the three LANs, and also done three times on the central VPN server for the 3 LANs it connects (some simplifications can exist, described in the end notes). I'll explain what has to be done with the example of connection given by OP, by following the packet's travel and adding configuration changes needed for this packet to continue to its correct destination. ![]() ![]() The problem is the packet's source IP remains foreign to the destination network, so many services on the sibling network (router's webui with restricted remote access, ssh on the machines etc) drop such packets. Say I am at the 192.168.0.20 machine, and I want to access the 192.168.10.20 device ("sibling" network unit over the VPN). Objects in orange visualize the VPN communication, objects in blue - LAN or WAN communication. I can understand I need to set up NAT on every VPN gateway device, so that packets from the "sibling" networks would not be dropped as foreign. I can connect seamlessly to every device in all of the networks with their local IPs, but most of the time the packets from the foreign networks get dropped by all devices other than those with public web interfaces (printers, local web servers etc). network connects to the VPN via a single VPN "gateway" (actually a peer with IP fowarding set to "on", one of them is running Windows 10 Home, two others run Linux) with 192.168.10 LAN address and 10.11.12.2-4 VPN address, and each corresponding WAN/LAN router (192.168.1) is set up to route 10.11.12.0/24 addresses to the local VPN "gateway" peer (192.168.10) as a static route. I have an SBC running Arch Linux that I use as a VPN server (as it is the only device having a globally accessed IP address not NATed by ISPs) to connect three different networks.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |