Hello,
I had the OpenVPN working successfully and I was able to connect remotely to my home network from abroad 
The interface is tun0
Now I am looking to anonymize part of my traffic (the deluge one) so I installed a package that installs a VPN client. The interface is tun1
The problem is that when the client is installed and working, I am not able to reach my home network with OpenVPN, I guess it has something to do with routes or iptables. here is my configuration
root@DietPi:/home/dietpi# route -v
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.117.78.1 128.0.0.0 UG 0 0 0 tun1
default 192.168.31.1 0.0.0.0 UG 0 0 0 eth0
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
10.8.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.117.78.0 0.0.0.0 255.255.254.0 U 0 0 0 tun1
128.0.0.0 10.117.78.1 128.0.0.0 UG 0 0 0 tun1
192.168.31.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
194.59.249.243 192.168.31.1 255.255.255.255 UGH 0 0 0 eth0
Chain OUTPUT (policy DROP)
target prot opt source destination
DROP tcp -- anywhere anywhere tcp dpt:53
DROP udp -- anywhere anywhere udp dpt:53
ACCEPT all -- anywhere 192.168.0.0/16
ACCEPT all -- anywhere 10.0.0.0/8
ACCEPT all -- anywhere 172.16.0.0/12
ACCEPT all -- anywhere 104.20.26.217
ACCEPT all -- anywhere 172.67.17.175
ACCEPT all -- anywhere assets.windscribe.com
ACCEPT all -- anywhere 172.67.203.127
ACCEPT all -- anywhere 104.21.93.29
ACCEPT all -- anywhere 104.21.53.216
ACCEPT all -- anywhere 172.67.219.39
ACCEPT all -- anywhere 104.21.65.74
ACCEPT all -- anywhere 172.67.189.40
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere localhost
ACCEPT all -- anywhere 194.59.249.243
Can anyone advise what am I missing? My home network sits at 192.168.31.X and the network that OpenVPN creates is 10.8.0.X , and the one that the VPN client creates is 10.117.X.X
Thank you
Indeed the initial connection from VPN clients to your server through eth0 is âansweredâ through the upstream VPN tunnel (hence never reaches the client) because of the routes. When a VPN client connection is up and you concurrently want to allow remote connections to that host, you need to setup a routing table for those, either based on an application user or for initially incoming connections on a certain port or in general.
iptables can be used to mark packets based on conditions and ip rules can be used to apply a different routing table for packets based on the mark.
But I need to dig out the details.
usually trendy has some experience with iptables
You can omit the iptables part, if the rule is something simple.
There was a similar topic here.
In such cases I prefer to leave the default gateway to the ISP and manually add the services or hosts which need to be routed over the tunnel.
Nice, iif for incoming interface and oif for outgoing interface, right?
In this case I think itâs not that easy because the initial incoming VPN connection request is coming though the regular WAN interface and outbound connections from the local VPN server shall still use the upstream VPN tunnel. So itâs indeed about inbound connections vs unbound connections. Not sure if ip rules has some syntax for this?
Yes!
It is easy, you can make a rule to bind the source port of the vpn server to the routing table that uses the wan uplink. Instead of iif, use the sport selector.
Ah nice. So all packets from that port will be leaving on eth0, but that is fine since that port is for establishing the VPN connection only anyway, not for communication though the tunnel. That method should work pretty will for e.g. allowing remote connections to a BitTorrent server while it is connected to a VPN. Much easier than connection marks, many thanks for sharing 
.
Thanks
Could you put an example of the command and where I can make it permanent?
An example would be:
ip route add to default via 10.10.10.1 table 100
ip rule add sport 1234 to default lookup 100 prio 16010
Change the ip to the one of the isp router and the port to the one you are using for the vpn server.
You can add it in rc.local to be permanent.
I have added
ip route add to default via 192.168.31.1 table 100
ip rule add sport 1194 to default lookup 100 prio 16010
ip rule add sport 443 to default lookup 100 prio 16010
ip rule add sport 943 to default lookup 100 prio 16010
Since the OpenVPN uses 443 and 943 TCP and 1194 UDP by default.
But I still have no luck connecting from outside to the internal VPN, it times out
First of all OpenVPN is udp/1194, the rest belong to other protocols. But which one are you using?
Also if you are adding multiple ports you should also change the sequence number, as now the first two are overwritten by the third.
Ok thank you. I tried at the beginning only with 1194 but ot didnât connect so I added the other two which I thought they were also needed for Openvpn.
I am using the default installer from dietpi for Openvpn slño if 1194 UDP is enough i can leave the first one only.
Still it doesnât get through
You can verify the port with ss -tunlp | grep vpn
Other than that post the following: ip -4 addr; ip -4 ro list table all; ip -4 ru
The fist command has no return, the second gives a lot of information
dietpi@DietPi:~$ ss -tunlp | grep vpn
dietpi@DietPi:~$ ip -4 addr; ip -4 ro list table all; ip -4 ru
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
inet 192.168.31.254/24 brd 192.168.31.255 scope global eth0
valid_lft forever preferred_lft forever
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
inet 10.8.0.1 peer 10.8.0.2/32 scope global tun0
valid_lft forever preferred_lft forever
6: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
inet 10.121.34.39/23 brd 10.121.35.255 scope global tun1
valid_lft forever preferred_lft forever
default via 192.168.31.1 dev eth0 table 100
0.0.0.0/1 via 10.121.34.1 dev tun1
default via 192.168.31.1 dev eth0 onlink
10.8.0.0/24 via 10.8.0.2 dev tun0
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1
10.121.34.0/23 dev tun1 proto kernel scope link src 10.121.34.39
37.120.136.243 via 192.168.31.1 dev eth0
128.0.0.0/1 via 10.121.34.1 dev tun1
192.168.31.0/24 dev eth0 proto kernel scope link src 192.168.31.254
local 10.8.0.1 dev tun0 table local proto kernel scope host src 10.8.0.1
broadcast 10.121.34.0 dev tun1 table local proto kernel scope link src 10.121.34.39
local 10.121.34.39 dev tun1 table local proto kernel scope host src 10.121.34.39
broadcast 10.121.35.255 dev tun1 table local proto kernel scope link src 10.121.34.39
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
broadcast 192.168.31.0 dev eth0 table local proto kernel scope link src 192.168.31.254
local 192.168.31.254 dev eth0 table local proto kernel scope host src 192.168.31.254
broadcast 192.168.31.255 dev eth0 table local proto kernel scope link src 192.168.31.254
0: from all lookup local
16010: from all sport 1194 lookup 100
32766: from all lookup main
32767: from all lookup default
Not related, but I also have realised that thr no-ip ddns script is updating to the wrong ip even when I mark eth0 as the interface for updating.
What about this?
grep port /etc/openvpn/*
grep port /etc/openvpn/*
grep: /etc/openvpn/client: Is a directory
grep: /etc/openvpn/easy-rsa: Is a directory
grep: /etc/openvpn/server: Is a directory
/etc/openvpn/server.conf:port 1194
Also
netstat -putan | grep 1194
udp 0 0 0.0.0.0:1194 0.0.0.0:* 1240/openvpn
[/code]
netstat is not included in dietpi and is deprecated, ss is the successor. Anyway, we have established the openvpn server is running on udp/1194
Install tcpdump if you donât have it already and run: sudo tcpdump -i eth0 -evn udp port 1194
Then try to connect from the client, let it capture a few packets, stop with Ctrl-c and paste here the output.
Probably itâs required to add âdev eth0â to the ip route, to force it using the right device as well.
It doesnât hurt to add it, however the dietpi shouldnât have any issues finding the 192.168.31.1 as it is directly connected to the eth0.
Where should I add the dev flag? What other things I can do?