Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Openvpn blocks incoming apache httpd and ssh connections
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
happysmash27
n00b
n00b


Joined: 28 Mar 2016
Posts: 36

PostPosted: Thu Jan 11, 2018 2:45 am    Post subject: Openvpn blocks incoming apache httpd and ssh connections Reply with quote

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?
Back to top
View user's profile Send private message
szatox
Veteran
Veteran


Joined: 27 Aug 2013
Posts: 1707

PostPosted: Thu Jan 11, 2018 9:45 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
benchaney
n00b
n00b


Joined: 28 Dec 2017
Posts: 27

PostPosted: Thu Jan 11, 2018 10:23 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
happysmash27
n00b
n00b


Joined: 28 Mar 2016
Posts: 36

PostPosted: Sun Jan 14, 2018 3:14 am    Post subject: Reply with quote

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

Code:
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
Code:
ip -a
looks super useful! I thought I put everything, but after re-reading, I realize that I didn't include it!

Code:
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.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13028

PostPosted: Sun Jan 14, 2018 5:43 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
happysmash27
n00b
n00b


Joined: 28 Mar 2016
Posts: 36

PostPosted: Thu Feb 22, 2018 2:28 am    Post subject: Sorry for the late reply. I procrastinate sometimes... Reply with quote

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...
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13028

PostPosted: Fri Feb 23, 2018 2:53 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum