IPtables configuration for different addresses?

[Bosse_B]

I have set up an OpenVPN server on my RPi3 and I have configured it to route traffic to the LAN via IPTABLES.
It is all working when I am connected by Ethernet, but if I connect by WiFi instead I have to change the IPTABLES commands, which is a big hassle.
Is there a way to prepare the IPTABLES such that it will forward traffic to the interface actually in use without me knowing the exact address beforehand?

The command I have used when setting it all up is this:

Code: Select all

sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j SNAT --to-source 192.168.23.150

The 150 IP address is the eth0 address it will get for this network, if I connect by WiFi instead the address will be 192.168.23.153.
And if I move the RPi unit to my other house it will be connecting to network 192.168.45.xxx instead.
It would be soo much easier if there would be a way to make this work without having to edit the IPTABLES settings all the time.

[allfox]

Greetings.

That's why we need the MASQUERADE target: http://www.iptables.info/en/iptables-ta ... RADETARGET

So you might use:
sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j MASQUERADE

The "! -d" part is for filtering off those packet going back to 10.8.0.0/24.

I made this line up without test it.

[Bosse_B]

That's why we need the MASQUERADE target
So you might use:
sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j MASQUERADE

The "! -d" part is for filtering off those packet going back to 10.8.0.0/24.

OK, thanks!
If I understand this correctly then all traffic coming in on 10.8.0.0 will be routed out on the external IP address of the RPi (eth0), which does not have to be known beforehand?

Since this is a VPN routing I don't think it makes sense blocking data coming in on eth0 to reach the tunnel the other direction, so it might not be wise to use ! -d in the command. Or did I misinterpret your comment? Or maybe incoming items are handled by the OpenVPN server anyway...

This will work so I don't have to mess with the IPTABLES syntax whenever I move the RPi to a different network and therefore get a different IP address.
Unfortunately I have found that there are more configuration files involved in the OpenVPN server which also have entries for the IP address.
So I still have some work to do in order to automate the OpenVPN server so it adapts to the environment it sits on.

[allfox]

MASQUERADE is SNAT. It would read the --to-source parameter from the actual interface which are used to send the packet. In your case, this interface could be eth0 or wlan0.

The iptables do not route packets. Routing tables do that. So if you have both the eth0 and the wlan0 connected, you need to check the "ip route" to tell which address is using for the default route. It should be eth0 in such situation, as the wlan0 should have a bigger metric. (bigger metric means slower, so we prefer a smaller metric)

The "! -d" part is a strange idea which I learnt from miniupnpd's source, you could ignore it.




The "! -d" and the "-s" conditions are connected with AND operator, so only when they both are meet, would the jump be executed. Those data coming into eth0 from the other side would have a different source address than the "-s" part, so this rule won't execute on them.

In fact, I think without the "! -d" part, the line would still work with normal circumstance. However I read this rule from miniupnpd's source code: https://github.com/miniupnp/miniupnp/bl ... es_init.sh

Code: Select all

$IPTABLES -t filter -A FORWARD -i $EXTIF ! -o $EXTIF -j MINIUPNPD

It is for blocking those packet who has a source and a destination in the very same network. Normally, this just won't happen, as in a LAN, data could be exchanged in link layer, so there won't be IP packet routing. But miniupnpd have this.

I could imagine a client made up a bad packet with the destination IP in the same LAN, then send it to the router. If the router accept the packet, then the receiver, who is in the same LAN, would think he is talking to the router, while in fact he is talking to another client in the LAN. This situation is abnormal anyway.