How to set up iptables on dual homed OpenVPN server

BobAGI

I have a Raspberry Pi3B box where I have set up OpenVPN server as I have on a number of other units before.
But this is different in that it is dual homed, it has both an eth0 and a wlan0 network interface.
Either or both can be used depending on where and how it is hooked up when it starts.

Now I wonder how to set up openvpn and iptables such that I don't have to specify which interface is going to be used?
Both interfaces are getting an address from DHCP in the same network and I have reserved x.x.x.173 and 174 for the two connections in the router. So both use the same Internet gateway etc.

What I want is to have openvpn listen on all network interfaces (which I think it does out of the box).
I also want it to route traffic over the same network as it was connected through, so if a client connects on 173 traffic will go through 173 and the same for 174.

QUESTIONS:
1. OpenVPN server settings
Is there any special configuration I have to use in order for the server to listen to both interfaces?
I thought that I could create 2 port forward rules in the router, one for x.x.x.173:1194 and the other for x.x.x.174:1194 where the incoming port would be 1194 for the eth0 interface and 1195 for the wlan0 interface but both pointing to the 1194 port on the RPi.
Or do I have to create a second openvpn server instance that listens on 1195 and not translate the port number in the router?

2. IPTABLES setup
This is where I am having trouble since I am not really understanding the inner workings of iptables...
In the past I have had only a single interface and in the iptables entries the network interface was spelled out with the IP address.
But I think this is no good, you should not have to reconfigure iptables if the box gets a new address, right?
So how should the proper iptables rules look like to cover both interfaces without specifying their network addresses?

Currently I have the following for testing:

sudo iptables-save
# Generated by iptables-save v1.4.21 on Tue May 29 09:20:48 2018
*filter
:INPUT ACCEPT [350:29013]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [304:44808]
COMMIT
# Completed on Tue May 29 09:20:48 2018
# Generated by iptables-save v1.4.21 on Tue May 29 09:20:48 2018
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [2:134]
:POSTROUTING ACCEPT [2:134]
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j SNAT --to-source 192.168.119.173
-A POSTROUTING -s 10.8.0.0/24 -o wlan0 -j SNAT --to-source 192.168.119.174
COMMIT
# Completed on Tue May 29 09:20:48 2018

I would like destination to be the same as from where the client connected. And I do not want to specify the IP address in the rule, it should be the interface itself, but how?
And what about MASQUERADE? I have seen this in iptables before, is it needed and if so how do I create it properly?

I am sorry if these are "basic" questions but I never got my head around iptables so I am using cook-book instructions here and they differ...

TinCanTech

Do you mean one of the books listed here ?
https://openvpn.net/index.php/open-source/books.html

BobAGI

Well, not really....
I meant searching for and reading various webpages describing how to set up a working OpenVPN system.
Everything on OVPN itself I try to find in the help pages but the iptables setup seems to be a bit overlooked there...
Anyway, the views of authors of the how-to cookbook style pages seem to differ a lot regarding how to set up iptables...
Over the years I have tried a few different ones and they seem to work kind of, but they are not so complex as what I am asking here...

TinCanTech

TinCanTech wrote Do you mean one of the books listed here ?
https://openvpn.net/index.php/open-source/books.html

BobAGI wrote Well, not really....
I meant searching for and reading various webpages

ah so ..

If you do not specify --local in your server config then openvpn will listen on all available interfaces.
After that, with your proposed setup, I do not know what will happen .. I always specify --local

BobAGI

Here is my not yet fixed server.conf file on the RPi3 box:
Edit: After posting this reply I see that the comments in the conf file have been removed.
I have actually a first line in the file that reads like this:

;local 192.168.117.174  #bind to all if commented out

So this way it will listen on both interfaces, which is really what I want.

;local 192.168.117.174 #bind to all if commented out
dev tun
proto udp
port 1196
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/BBOpenVPN.crt # YOUR CRT NAME
key /etc/openvpn/keys/BBOpenVPN.key # YOUR KEY NAME
dh /etc/openvpn/keys/dh1024.pem
server 10.8.0.0 255.255.255.0
# Add route to Client routing table for the OpenVPN Subnet
push "route 10.8.0.0 255.255.255.0"
# your local subnet
push "route 192.168.117.0 255.255.255.0"
push "dhcp-option DNS 192.168.117.1" # This should already match your router address and not need to be changed.
push "redirect-gateway def1"
duplicate-cn
keepalive 10 120
tls-auth /etc/openvpn/keys/ta.key 0
cipher AES-128-CBC
comp-lzo
persist-key
persist-tun
status /var/log/openvpn-status.log 20
log /var/log/openvpn.log
verb 4
#--- End of OpenVPN configuration file-----

I think this is OK, but what I don't yet know is how exactly to set up IPTABLES such that a client arriving on eth0 will talk through eth0 and one arriving on wlan0 will talk through wlan0..
There are 3 use cases here:
1) RPi3 connected to both eth0 and wlan0 (dual homed)
2) RPi3 connected only via wlan0 (pulled the ethernet cable out)
3) RPi3 connected only by eth0 (ifdown wlan0)
I would like the box to work without config changes in all of these cases so I can decide where to put it without having to mess with IPTABLES or OpenVPN reconfigurations.

TinCanTech

See --multihome in the manual.

BobAGI

Thanks!
That seems to be exactly what is needed for OpenVPN server.
But what about IPTABLES in this case? I still need to set up the firewall, right?

TinCanTech

BobAGI wrote That seems to be exactly what is needed for OpenVPN server.

Just so you are aware, there have been problems with --multihome in the past and I don't know what it's current status is considered to be .. You may get problems in the future.

BobAGI wrote But what about IPTABLES in this case? I still need to set up the firewall, right?

I guess so .. but that's out of scope for me. A brief scan of what you have now looks reasonable.

BobAGI

Would it be enough to just use the following (with the multihome entry in server.conf):

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o wlan0 -j MASQUERADE

Can it replace the SNAT command in my example above???

Pippin

As already written firewall is somewhat out of scope.

However, many don`t understand how packets flow, as I didn`t.
So take a look at the packet flow for better understanding of where to put rules if needed:

On SERVER side, just imagine wlan0 to be the same as eth0, so you have two physical (eth0/wlan0) and one virtual (tun0) interface.

Pippin

BobAGI wrote Can it replace the SNAT command in my example above???

It depends, if you can set routes on RPi`s gateway (your router i guess) it would be "more clean".
Those two rules could be replaced with one rule but both do the job:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j MASQUERADE

Really, it`s much better to learn and read iptables man page and then "read" above picture 😉

BobAGI

There are so many things related to Linux functionality and if you are not full-time on it it is very hard to know it all...
Anyway I now got the openvpn server running with the single IPTABLES line shown above.
I can connect fine and browse the Internet out of the remote router and communicate with servers on the remote LAN.
So all would be OK were it not for me looking at the openvpn log...

Here I find the stuff that usually is there when logging a client connect, but also this:

Thu May 31 23:33:11 2018 us=758049 BosseAspo/81.xxx.141.237:60506 MULTI: bad source address from client [fe80::74cb:69ac:c6e2:a264], packet dropped
Thu May 31 23:33:11 2018 us=818104 BosseAspo/81.xxx.141.237:60506 MULTI: bad source address from client [::], packet dropped
Thu May 31 23:33:11 2018 us=818264 BosseAspo/81.xxx.141.237:60506 MULTI: bad source address from client [fe80::74cb:69ac:c6e2:a264], packet dropped
Thu May 31 23:33:11 2018 us=818407 BosseAspo/81.xxx.141.237:60506 MULTI: bad source address from client [fe80::74cb:69ac:c6e2:a264], packet dropped

The lines repeat down the log for quite a while, so these are just a few examples.
It seems like there is some IPV6 handling involved, which is strange since I have disabled IPV6 altogether...
This is how I did that:

sudo nano /etc/sysctl.d/99-sysctl.conf
#Make sure these lines are active in the file:
net.ipv4.ip_forward=1
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1

#Then activate by:
sudo sysctl -p

I even went as far as suggested here:
Disabling IPv6 Kernel Module on Raspbian Stretch
I.e. editing the conf file and adding one line, then reboot:

sudo nano /etc/modprobe.d/ipv6.conf
blacklist ipv6

But still these log lines persist...

TinCanTech

You probably just need to turn IP forwaing Off at your client ..

Also, ip6tables :mrgreen:

BobAGI

Well, since I have deactivated ipv6 in the kernel I am assuming no ipv6 traffic is present.
So adding some rules (which) to the ip6tables should not affect anything.

Turning off IP forwarding at the client seems to contradict the reason one has an OpenVPN tunnel open in the first place.
How can I get any traffic through if routing through the tunnel is switched off? I don't understand.
My clients are Windows 7 PC and Android phones.

Or do you mean that there might be an OpenVPN client config file entry that switches off ipv6 forwarding specifically?
There might be some bogus stuff generated by Win7 that gets through the tunnel of course, but I have no idea how to block that.
----------------------
Edit:
I looked in the manual and found that there is a variation of udp/tcp that reads udp4/udp6/tcp4/tcp6 so first I tried editing my client OVPN configuration file like this:
proto udp4
Did not make a difference...

Next I tried to do the same on the server (in server.conf):
proto udp4

Restarted the service and tried to connect. But now I could not connect at all! So I had to replace the server side udp4 with just udp to be able to connect.
---------------------------
Anyway, is there some method to block this from being logged? I have read several posts that just says "it can be safely disregarded" but it is still being logged....
As it is now the absolute majority of the openvpn.log file consists of these messages effectively hiding the valid lines. 🙁
And they keep coming even though there is no traffic (from me), just the tunnel being open.
Happened over night when I had forgotten to close the tunnel before going to bed.

In fact it is surprising that the tunnel was up this morning since I have configured cron on the server side to reboot the server at 01:15 every night just to make sure it never hangs. Still this morning the tunnel was connected....

BobAGI

TinCanTech wrote You probably just need to turn IP forwaing Off at your client ..

How do you do that on a Windows 7 PC?
That is my client machine. Plus I have an Android phone that also could connect.

Also, ip6tables

On the server all ip6-related stuff should be off since the ip6 protocol has been removed from the kernel...
Trying to add a rule on the server results in this:

sudo ip6tables -A OUTPUT -j DROP
ip6tables v1.4.21: can't initialize ip6tables table `filter': Address family not supported by protocol
Perhaps ip6tables or your kernel needs to be upgraded.

So this shows that ipv6 is not active, and still I have these mysterious log entries coming in sometimes several every second....
I'd be happy just to disable logging this message altogether...

TinCanTech

BobAGI wrote Turning off IP forwarding at the client seems to contradict the reason one has an OpenVPN tunnel open in the first place.
How can I get any traffic through if routing through the tunnel is switched off? I don't understand.
My clients are Windows 7 PC and Android phones.

You only need ip forwarding on the client if you want access to the client side LAN from the server side (or a different client) .. judging from what you have posted, I do not believe you need ip forwarding to be enabled on your clients. So disable it (google windpows ip forward ..)

BobAGI wrote Anyway, is there some method to block this from being logged? I have read several posts that just says "it can be safely disregarded" but it is still being logged....

You could try a lower --verb value .. there is no specific option to turn off that message.

BobAGI wrote On the server all ip6-related stuff should be off since the ip6 protocol has been removed from the kernel...

You don't really need to do this but ok ..

BobAGI wrote Thu May 31 23:33:11 2018 us=758049 BosseAspo/81.xxx.141.237:60506 MULTI: bad source address from client [fe80::74cb:69ac:c6e2:a264], packet dropped

The fact is you can safely ignore it ..

BobAGI

Meanwhile I made an experiment:
- Re-enabled ipv6 by commenting out the stuff I had put into /etc/sysctl.d/99-sysctl.conf and /etc/modprobe.d/ipv6.conf
- Rebooted the server
- Added the following ip6tables rules:

sudo ip6tables -A OUTPUT -j DROP
sudo ip6tables -A INPUT -j DROP

- Connected OpenVPN from my Win7 PC
- Examined the openvpn.log file
Same as before....
Lots and lots of these MULTI loglines....

Then I edited server.conf and changed to verb 3, restarted openvpn and connected from Win7

Now the log contains only these "MULTI:" lines:

Fri Jun  1 13:57:11 2018 BosseAspo/81.xxx.141.237:64664 MULTI_sva: pool returned IPv4=10.8.0.2, IPv6=(Not enabled)
Fri Jun  1 13:57:11 2018 BosseAspo/81.xxx.141.237:64664 MULTI: Learn: 10.8.0.2 -> BosseAspo/81.170.141.237:64664
Fri Jun  1 13:57:11 2018 BosseAspo/81.xxx.141.237:64664 MULTI: primary virtual IP for BosseAspo/81.170.141.237:64664: 10.8.0.2

Finally I got rid of the bogus messages!
Don't know what else I am missing but I think I can live with this at least. 🙂