[email protected] wrote: > The VPS uses a dummy network of 10.2.0.0/24 > The local server+LAN use 10.1.0.0/24 > The vpn endpoints are 10.99.99.{1,2} -- nothing else on that subnet > > So IIUC that meets the non-overlapping subnet requirements
Yes. You'd be surprised how often I see questions from people where this isn't the case ! >> 2) You must have routing set up. > > Everybody always says that like it's supposed to be self-explanatory! :-) OK, I'll take a step back. A route is an instruction to the system that "packets meeting this rule should be sent out by this route". For most small/home networks there is only one - a "default route" via your internet router. If you do "ip route" then you'll also see a route for each connected subnet - the system sets that up automatically. So for LAN1, devices will just need a default route via 10.1.0.1 as all their traffic can be sent via server 1. On server 1, you will have a default route via your internet provider, and you'll need to add a route to 10.2.0.0/24 via 10.99.99.2 "ip route add 10.2.0.0/24 via 10.99.99.2" Correspondingly, on server 3 you need to add a route to 10.1.0.0/24 via 10.99.99.1. So, when a device (lets say 10.1.0.57) tries to talk to (say) 10.2.0.123, the packet flows and routes will go like : Device sends packet to server 1 using it's default route. Server 1 sees it has a route to 10.2.0.0/24 and so sends the packet to 10.99.99.2 (via the VPN). Server 3 looks in it's routing table and sees that it has a locally connected network for 10.2.0.0/24 and so do an ARP request to find the MAC address of the device to send the packet to. When the device replies, it uses it's default route to send the packet to server 3. Server 3 sees it has a route via 10.99.99.1 and so sends the packet that way. Server 1 sees that 10.1.0.0/24 is locally connected and uses ARP to find the MAC address of the device to send the packet to. >> So far this is basic IP addressing/routing stuff and doesn't (need to) >> involve Shorewall. > > So that's all in/on OpenVPN, like Tom said, right? Yes, it can be done in the OpenVPN setup. >> 3) Your rules/policies must allow the packet. > >> The only NAT you need to is to masq traffic out via the public ethernet >> connections. This most likely to masq the subnet for LAN1 via the public IP >> of server 1, and masq traffic for LAN2 via the public IP of server 3. >> It would be possible to configure masq for traffic from LAN2 via the public >> IP of server 1 and there may be valid uses for it. You could route traffic >> from LAN2 via the internet connection of server 1. In practical terms it's >> not useful since if server 3's internet is down then so is the VPN tunnel, >> and the traffic has to go via both internet connections before it gets >> masq'd out - so you can't take advantage of more generous bandwidth >> allowances. > > Ok, that just makes my head hurt. Too much "I understand this stuff already" > speak. > > Printing it out in double-spaced, large-type to re-read! ;-) OK, masq (short for masquerade) is the process (otherwise called NAT or NAPT) of translating the private addresses into public addresses before sending the packets out via the internet - and of course, keeping track of how it mapped the outbound packets so it can reverse the change for the reply packets coming back in. It's configured in Shorewall using the "masq" file - though on checking the man page online I see it's deprecated in favour of "snat". On server 1 your masq file would contain just : eth0 I think that's correct, and just means that all traffic routed out via that interface will be source address translated to the primary address of the interface. I had to look it up as my routers tend to have "somewhat more complexity" ! >> So using your numbers (and making assumptions of masks), on server 1 you >> need to masq : >> 10.1.0.0/24 and optionally 10.99.99.0/24 and 10.2.0.1/24 to 192.0.2.1 >> On server 3 you need to mask : >> 10.0.1/24 and optionally 10.99.99.0/24 and 10.1.0.1/24 to 198.51.100.1 > > And by "need to masq" (or mask), that DOES mean rules in the Shorewall 'masq' > file? Yes, or in recent versions, the snat file. >> As for routing, two ways of doing it. >> You can do it at the OS layer - so when you bring up the VPN, add a post-up >> action to install routes to the other end (LAN2 on server1 and LAN1 on >> server 3). Or you can have Shorewall set it up by (IIRC) using the route >> rules (rtrules) file. > > Right now I'm no better off UNDERSTANDING, but at least I have stuff to read > & start at some more ! There are many ways of adding routes. You can do it manually - "ip route add ...". On Debian & derived systems, you can add lines to /etc/network/interfaces so that after bringing up an interface, it will add routes - "post-up ip route add ...". I think OpenVPN can add routes as it brings up a tunnel. And Shorewall can add routes specified via the rtrules file. ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
