1

i have some issue with an OpenVPN concentrator while using TUN device. The scenario is that:

OpenVPN Server
VPN Subnet: 10.10.10.1/24

PC1 OpenVPN Client
VPN IP: 10.10.10.50
PC Local subnet/IP: 192.168.20.100

PC2 OpenVPN Client
VPN IP: 10.10.10.60
PC Local subnet/IP: 192.168.30.100

RemoteSite1
VPN IP: 10.10.10.70
Local Subnet: 192.168.80.0/24

RemoteSite2
VPN IP: 10.10.10.80
Local Subnet: 192.168.80.0/24

The PC1 connect to RemoteSite1 and the PC2 connect to RemoteSite2 but while using iroute one of the PCs reach the wrong remote site. This setup works perfectly while using TAP device. In order to avoid the network conflicts on the OpenVPN server there are not the routing rule for the remote sites, there is a specific lookup routing table for each PC like that:

root@openvpn~ # ip rule sh
0:  from all lookup local 
1:  from 10.10.10.50 lookup 1024
1:  from 10.10.10.60 lookup 1034
10: from all to 10.10.10.0/24 lookup main

And under each table: root@openvpn~ # ip route show table 1024 192.168.80.0/24 via 10.10.10.70 dev tap0

root@openvpn~ # ip route show table 1034
192.168.80.0/24 via 10.10.10.80 dev tap0

How can archieve the same setup but with TUN and iroute?

Improve this question

1 Answer 1

Reset to default
2

I don't think you can do that.

TUN is routed (OSI layer 3), and it isn't possible to have two identical routes for a single subnet in this way (you would need at least some kind of difference in metric). TAP operates at OSI layer 2, where MAC lookups are possible, which is how your setup is working (when it works).

For TUN to work in this situation, your best bet might be to split your /24 into two /25 networks, and assign one side to each location.

Improve this answer
2
  • 2
    I can confirm that you can't have two identical routes for a single subnet when TUN is routed (OSI layer 3). Also, if you need to bridge two ethernet segments in two different locations - then use tap. in such setup you can have computers in the same ip subnet (eg 10.0.0.0/24) on both ends of vpn, and they'll be able to 'talk' to each other directly without any changes in their routing tables. vpn will act like ethernet switch. this might sound cool and is useful in some cases but I would advice not to go for it unless you really need.
    – Net Runner
    Mar 3, 2017 at 16:25
  • @iwaseatenbyagrue thank you very much for the explanation, yes with TAP this setup always work. I have a VPN concentrator with almost 300 Clients (eWon gateways) that have an older version of OpenVPN < 2.2 and so I need to do this trick because the network mapping is not supported. I have another VPN concentrator with 650 Clients that have OpenVPN 2.3 and I don't need to do this trick because I can use the network mapping and the use on the VPN concentrator side and I can do a normal routing rules.
    – DarkVex
    Mar 3, 2017 at 17:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .