[email protected] wrote: > launch query & axfr FROM my desktop AT a nameserver across a VPN -- > *NOT* a public one -- and make sure the responses get sent back correctly. > > I'll admit I've gotten to the point where I've just been trying things > blindly & randomly. When I've turned on logging, I keep getting DROPs on one > or the other VPN endpoint. > > So I stopped monkeying & I've been re-reading the docs (wow! lots of them!), > and poists I can find, and have now gotten myself completely turned around > re: DNAT, SNAT, masq, NAT & individual rules. > > So time to ask! > > What (kind of) rules do I need on each shorewall5 instance to make sure that > the LAN1 <-> VPN endpoints <-> LAN2 "IP address mapping" is correct ?
OK, stop thinking about a VPN as "something special" - as far as the rest fo the network is concerned it's "just another network link". So for a device to talk to another device over this VPN, you need just a few things : 1) The different networks should all have separate and non-overlapping subnets. If you do this, then there is no need for any NAT whatsoever (within the network). 2) You must have routing set up. In this case, your desktop needs a default route via server 1. Server 1 needs a route to server 3 via the VPN *AND* a route to LAN2 via the VPN. Your server 3 needs a route to server 1 via the VPN and a route to LAN1 via server 1. Basically - pick a node on your diagram, imagine it going to another node, and each time it hits a router ask - does this router know how to forward this packet correctly. So far this is basic IP addressing/routing stuff and doesn't (need to) involve Shorewall. 3) Your rules/policies must allow the packet. You can set default policies and allow all internal traffic - then you need no rules for it to work. or you can set your policies to block everything and create rules to allow traffic you want. There's no right answer - just what's the best option for you and your requirements (including the old security vs complexity tradeoff). 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. One use would be to have traffic from LAN2 appear to come from a different location - can be useful for working around filters or geo-location blocks. 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 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. > I have 3 boxes > (1) local server > (2) local desktop > (3) VPS server > > They're arranged like this > > |- [eth0] -------- public internet > | > (1)---|- [eth1] -------- LAN1/switch ------- (2) > | > |- [tun0] -- VPN > | > | > | > |- [tun0] -- VPN > | > (3)---|- [dummy0] ------ LAN2 > | > |- [eth0] -------- public internet > > > & configured like this > > (1) local server > 3 interface > eth0 > IP(public) = 192.0.2.1 > eth1 > IP(LAN1,private) = 10.1.0.1 > lo > IP(local) = 127.0.0.1 > tun0 > IP(VPN,endpoint) = 10.99.99.1 > > runs: > authoritative & recursive DNS server > listens on > 10.1.0.1 port 53 > 127.0.0.1 port 53 > shorewall5 > > (2) Desktop > 2 interfaces > eth0 > IP(LAN1,private) = 10.1.0.10/24 > lo > IP(local) = 127.0.0.1 > > (3) VPS > 4 interfaces > eth0 > IP(public) = 198.51.100.1 > dummy0 > IP(LAN2,private) 10.2.0.1/24 > lo > IP(local) = 127.0.0.1 > tun0 > IP(VPN,endpoint) 10.99.99.2 > > runs: > recursive DNS server > listens on > 10.2.0.1 port 50053 > 127.0.0.1 port 53 > shorewall5 ------------------------------------------------------------------------------ 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
