[Shorewall-users] DNS responses across a VPN ? DNAT, SNAT, NAT, masq, oh my"!

[a***@myfastmail.com]

I've started using Shorewall v5. OK, more "working on it" than "started" :-/

For the setup below, I want to make sure I can

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 ?

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

Do I need DNAT, SNAT, masq? On one box or both?

The tests I want to have work are, from the Desktop's shell

dig -t A example.com @10.2.0.1 -p 50053
dig -t axfr example.com @10.2.0.1 -p 50053

-AJ

[Tom Eastep]

Post by a***@myfastmail.com
I've started using Shorewall v5. OK, more "working on it" than "started" :-/
For the setup below, I want to make sure I can
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 ?
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
Do I need DNAT, SNAT, masq? On one box or both?

None of those. This isn't a Shorewall configuration problem; it is a
basic routing problem.

- - Box number 1 needs to know that it must route to 10.2.0.1/24 via the
VPN.
- - Box number 2 needs to know that it must route to 10.1.0.0/24 via the VPN

If you are using OpenVPN, that is accomplished by having each side
'push' the appropriate route(s) to the other side during VPN startup.

You should set this up with shorewall cleared on both sides and get it
working that way first. Then add Shorewall and configure any firewall
rules you want, together with masquerading your local network to the
internet.

- -Tom
- --
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________

[Simon Hobson]

Post by a***@myfastmail.com
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.

Post by a***@myfastmail.com
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
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
recursive DNS server
listens on
10.2.0.1 port 50053
127.0.0.1 port 53
shorewall5

[a***@myfastmail.com]

Hi

Post by Simon Hobson
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".

Well, I'd started poking at the VPN routes only, per Tom's comment. Now considering yours too ...

Post by Simon Hobson
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).

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

Post by Simon Hobson
2) You must have routing set up.

Everybody always says that like it's supposed to be self-explanatory! :-)

...

Post by Simon Hobson
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?

Post by Simon Hobson
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! ;-)

Post by Simon Hobson
10.1.0.0/24 and optionally 10.99.99.0/24 and 10.2.0.1/24 to 192.0.2.1
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?

Post by Simon Hobson
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 !

Thanks!

-AJ

[Simon Hobson]

Post by a***@myfastmail.com
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 !

Post by a***@myfastmail.com

Post by Simon Hobson
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.

Post by a***@myfastmail.com

Post by Simon Hobson
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.

Post by a***@myfastmail.com

Post by Simon Hobson
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" !

Post by a***@myfastmail.com

Post by Simon Hobson
10.1.0.0/24 and optionally 10.99.99.0/24 and 10.2.0.1/24 to 192.0.2.1
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.

Post by a***@myfastmail.com

Post by Simon Hobson
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.