Openvpn blocks incoming apache httpd and ssh connections

[happysmash27]

This is on a computer connected directly to the internet. How can I make it so that Openvpn does not stop these connections from coming through, so I can use a VPN without taking my website offline?

[szatox]

Please post you openVPN config.
Obviously, you can skip "private" bits like passwords or private keys, though pointing out the missing things sometimes makes debugging it easier.
Also, 'netstat -nlp' may come in handy, as well as 'ip a'

Finally, the problem may not actually be with your vpn server, so please add 'ip a' and 'ip route' from your failing client.

[benchaney]

What is your desired end goal? If you want sshd and apache to be accessible via the VPN, the problem is probably related to port forwarding. If you want them to be accessible by connecting using your ip address (not your VPN's ip address), the problem is probably related to the fact that openvpn modifies your ip routes.

[happysmash27]

Oh gosh, this will be complicated... I did quite a lot of changes in [my previous post](https://forums.gentoo.org/viewtopic-t-1074946.html), so it will be a lot to show...

[Hu]

As an aside, this forum doesn't use Markdown style links. URL-like text will be autolinked, or you can use [url=protocol://host/path]descriptive text[/url] (as opposed to the [descriptive text](protocol://host/path) that you tried to use).

To the problem at hand: Based on that route, I like the theory proposed by benchaney. Normally, traffic must arrive and depart via the same route (advanced configurations can break this rule, but it's better not to need to break it). Your VPN routes separately route the upper half of the Internet (128.0.0.0/1) and the lower half of the Internet (0.0.0.0/1) through the VPN. This was probably done to make those more specific than the default route. Regardless, it means that any traffic arriving over the Internet, if it does not match a better rule, will be considered to have arrived from the wrong place. That would provoke the reverse path filter into dropping it, unless rp_filter is disabled. (There is a special rule for the VPN server, so that you do not hit this restriction for the datagrams it sends containing your VPN payload.)

To confirm that this is the case, you could try adding a corresponding specific route for an Internet host that will then try to use your public service. This does not scale, but is a simple test. Supposing you had a shell (or a friend with a shell) on 16.17.18.19, you would add a new route 16.17.18.19 via same-host as via for 68.114.36.12 dev enp8s0f0. Once that route exists, connections from 16.17.18.19 to the public IP should be permitted while the VPN is up. Test to confirm that. If that doesn't work, stop and post back. Include the modified ip route so we can confirm the test was valid. Obscuring 16.17.18.19 is fine.

Assuming that did work, now, you need to fix it for the general case. If you want to allow arbitrary incoming connections from the Internet to the system, you need one of:

1. An advanced routing configuration to permit the asymmetric paths that result.
2. A modified routing table that only routes traffic over the VPN for specific hosts, none of which will be able to use your public services.
3. Fake a hybrid of #1 and #2 using network namespaces.

#3 is easiest to reason about, but may or may not satisfy your use case, depending on why you are running this VPN and which hosts it is expected to serve. From the extensive ip addr output, it looks like you have a wireless card attached to a local AP. Are clients that use the AP expected to route to this machine, and from it out through the VPN?

[happysmash27]

[Hu]

The simplest solution, in my opinion, would be to run OpenVPN in a network namespace. Place the VPN-using programs in the namespace with it. Place the non-VPN-using programs in the initial network namespace, so that they do not see the VPN at all. The wireless clients will also effectively be associated with the initial network namespace, so they too will not see the VPN.