Transmitting packages which have the same IP address as the remote

johanness

Hi, I noticed that OpenVPN drops IP packages which have a destination that matches the address given in the `remote`-configuration. I wanted to use the configuration below to connect two bridge interfaces on two different machines.

remote example.org
port 1194
proto udp
dev tap

secret ../static.key 0
cipher AES-256-CBC

script-security 2
setenv target_bridge br0
up ../connect_bridge.sh

persist-tun
persist-key
user nobody
group nobody

With this configuration, I am unable to send packages with example.org as destination address over the VPN. Note that these packages were not sent by OpenVPN (which would obviously not work) but other devices on the bridge.

The VPN was intended for a migration from one physical machine to another. I wanted to move devices (i.e. VMs) from one physical machine to another without having to change their configuration at the same time. However, this means that the devices were still using the previous machine as gateway. So if they want to access any external IP address, they were trying to send the package through the VPN. Unfortunately, this also includes the external IP address of the previous machine itself. Since OpenVPN was dropping the packages to this specific IP address, I had the strange situation that the VMs could reach all address on the internet except for the external IP address the previous host.

It took some time to figure that out. I have not found this behavior documented anywhere. I think it should at least be mentioned. I am not sure about the reason, although I have some speculations. Anyway, does someone know whether it is possible to disable this filter since it is clearly causing trouble for my use case?

As a workaround, I am currently using a separate pair of public IP address for the physical machines exclusively for connecting both OpenVPN instances.

TinCanTech

johanness wrote I noticed that OpenVPN drops IP packages which have a destination that matches the address given in the `remote`

Try --allow-recursive-routing

johanness

TinCanTech wrote Try --allow-recursive-routing

Thanks. It did work within my tests. The migration is finished, but I think I will use this technique again in the future. So, I am still happy to have a solution. I am not sure why I haven't noticed this option within the manpage. Maybe because the description is rather scarce and does mention “tun packets”. So maybe I thought it is only relevant for tun (unlike tap) connections?

Anyway, thanks for your help.

TinCanTech

That it works for you is a surprise to me!

It is not an option I would use.

johanness

I guess my scenario is somewhat special, since the systems which are using the VPN have different routing tables than the host which is running OpenVPN. The VPN is not for the host which is running OpenVPN, but for some VMs on that host.