# 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...

```
x86_64-Pig ~ # ip route show                        

0.0.0.0/1 via 193.183.116.1 dev tun0 

default via <ip address similer to mine, ends with 1> dev enp8s0f0 proto static metric 100 

25.0.0.0/8 dev ham0 proto kernel scope link src 25.76.239.160 

68.114.36.12 via <ip address similer to mine, same as previous> dev enp8s0f0 proto dhcp metric 100 

<same similer ip from earlier, except with the 1 changed to a 0>/23 dev enp8s0f0 proto kernel scope link src <my ip> metric 100 

128.0.0.0/1 via 193.183.116.1 dev tun0 

192.168.27.0/24 dev wlp6s0 proto kernel scope link src 192.168.27.1 

193.180.164.50 via <same similer ip which ends with 1> dev enp8s0f0 

193.183.116.0/26 dev tun0 proto kernel scope link src 193.183.116.7 

x86_64-Pig ~ # ip rule show           

0:      from all lookup local 

270:    from 192.168.0.0/24 lookup lan 

270:    from 192.168.27.0/24 lookup lan 

32766:  from all lookup main 

32767:  from all lookup default 

x86_64-Pig ~ # ip route show table 270

default via <same similer ip which ends with 1> dev enp8s0f0 

192.168.27.0/24 dev wlp6s0 scope link 

x86_64-Pig ~ # iptables -L            

Chain INPUT (policy ACCEPT)

target     prot opt source               destination         

ACCEPT     all  --  anywhere             anywhere            

ACCEPT     all  --  anywhere             anywhere            

REJECT     udp  --  anywhere             anywhere             udp dpt:bootps reject-with icmp-port-unreachable

REJECT     udp  --  anywhere             anywhere             udp dpt:domain reject-with icmp-port-unreachable

ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh

ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http

ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:https

DROP       tcp  --  anywhere             anywhere             tcp dpts:0:1023

DROP       udp  --  anywhere             anywhere             udp dpts:0:1023

Chain FORWARD (policy DROP)

target     prot opt source               destination         

DROP       all  --  anywhere             192.168.0.0/16      

ACCEPT     all  --  192.168.0.0/16       anywhere            

ACCEPT     all  --  anywhere             192.168.0.0/16      

ACCEPT     all  --  anywhere             192.168.0.0/16      

ACCEPT     all  --  anywhere             192.168.0.0/16      

ACCEPT     all  --  anywhere             192.168.0.0/16      

ACCEPT     all  --  anywhere             192.168.0.0/16      

ACCEPT     all  --  anywhere             192.168.0.0/16      

Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination         

x86_64-Pig ~ # cat /etc/openvpn/AzireVPN-se.conf

# AzireVPN.com configuration generator

# Location: sweden

# Protocol: udp

# Port: random

# DNS-leak protection: yes

client

dev tun

proto udp

remote se.ovpn-ext.azirevpn.net 1194

remote se.ovpn-ext.azirevpn.net 443

resolv-retry infinite

auth-user-pass /etc/openvpn/loginAzire.conf

nobind

persist-key

persist-tun

remote-cert-tls server

reneg-sec 0

keepalive 10 60

script-security 2

#up /etc/openvpn/update-resolv-conf

#down /etc/openvpn/update-resolv-conf

mute-replay-warnings

explicit-exit-notify 3

cipher AES-256-CBC

auth SHA512

tls-version-min 1.2

<ca>

-----BEGIN CERTIFICATE-----

<long certificate>

-----END CERTIFICATE-----

</ca>

key-direction 1

<tls-auth>

-----BEGIN OpenVPN Static key V1-----

<openVPN static key>

-----END OpenVPN Static key V1-----

</tls-auth>

verb 3

x86_64-Pig ~ #
```

I'm not sure if I needed to redact everything I did, but why not make sure anyway? 

Pre-submit edit:

Holy cow, this 

```
ip -a
```

 looks super useful! I thought I put everything, but after re-reading, I realize that I didn't include it!

```
x86_64-Pig ~ # ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet <super top secret ip address you'll never guess /s>/8 scope host lo

       valid_lft forever preferred_lft forever

    inet6 ::1/128 scope host 

       valid_lft forever preferred_lft forever

2: enp8s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000

    link/ether 00:25:90:f1:67:a4 brd ff:ff:ff:ff:ff:ff

    inet <public ip>/23 brd <subnet of public ip>.255 scope global dynamic enp8s0f0

       valid_lft 8874sec preferred_lft 8874sec

    inet6 fe80::ba3c:bc7c:e8ed:1f62/64 scope link 

       valid_lft forever preferred_lft forever

3: enp8s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000

    link/ether 00:25:90:f1:67:a5 brd ff:ff:ff:ff:ff:ff

4: enp5s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000

    link/ether 00:25:90:f1:67:a2 brd ff:ff:ff:ff:ff:ff

5: enp5s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000

    link/ether 00:25:90:f1:67:a3 brd ff:ff:ff:ff:ff:ff

6: wlp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000

    link/ether da:f9:f4:a8:03:34 brd ff:ff:ff:ff:ff:ff

    inet 192.168.27.1/24 brd 192.168.27.255 scope global wlp6s0

       valid_lft forever preferred_lft forever

7: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000

    link/ipip 0.0.0.0 brd 0.0.0.0

8: ip_vti0@NONE: <NOARP> mtu 1364 qdisc noop state DOWN group default qlen 1000

    link/ipip 0.0.0.0 brd 0.0.0.0

9: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000

    link/sit 0.0.0.0 brd 0.0.0.0

10: ham0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1404 qdisc pfifo_fast state UNKNOWN group default qlen 1000

    link/ether 7a:79:19:4c:ef:a0 brd ff:ff:ff:ff:ff:ff

    inet 25.76.239.160/8 brd 25.255.255.255 scope global ham0

       valid_lft forever preferred_lft forever

    inet6 fe80::7879:19ff:fe4c:efa0/64 scope link 

       valid_lft forever preferred_lft forever

12: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100

    link/none 

    inet 193.183.116.206/26 brd 193.183.116.255 scope global tun0

       valid_lft forever preferred_lft forever

    inet6 2a03:8600:1001:1054::100c/64 scope global 

       valid_lft forever preferred_lft forever

    inet6 fe80::c27b:d30c:f40a:cc43/64 scope link stable-privacy 

       valid_lft forever preferred_lft forever

```

Hmm, okay, maybe more text does not mean more amazing network diagnostics, but it still looks quite useful. Thanks for the extra ip command!

Post-submit edit:

As for my desired goal, yes, it is for it to be accessible from my public ip address. I am trying to host a public web server, and this VPN does not support static IP addresses from what I understand.

----------

## 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:An advanced routing configuration to permit the asymmetric paths that result.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.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 wrote:*   

> Are clients that use the AP expected to route to this machine, and from it out through the VPN?

 

No; it was actually a really big challenge to have them not go through the VPN initially. What I am looking for, however, is to have programs which are not SSH, Apache, or the Minecraft server, such as Firefox and Transmission, to go through the VPN. 

I am very sorry for the late reply by the way; I often start something, stop, then start again a while later :( . Hopefully the improvements I am making to my scheduling will stop this from happening in the future...

----------

## 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.

----------

