Multihome server issues

Lupine

This should be a simple setup, and hopefully a simple straight forward issue, with a solution close by.

Here is the configuration for my multihome Linux, Fedora 20, server. This is my "everything" server. I use it for SSH, HTTPS, MediaTomb, Firewall/Router (iptables), DHCP, DNS.....everything:
eth0 == External ISP IP, let's just say: X.X.X.X
eth1 == Internal LAN: 192.168.10.1 255.255.255.0 (all my PCs in my house go to/through this interface)
tun0 == 10.8.0.1 255.255.255.255

server.conf:

port 1194
proto udp
dev tun
multihome
tls-server
ca keys/ca.crt
cert keys/lup64.crt
key keys/lup64.key
dh keys/dh1024.pem
mode server
ifconfig 10.8.0.1 10.8.0.2
ifconfig-pool 10.8.0.4 10.8.0.255
route 10.8.0.0 255.255.255.0
keepalive 10 60
inactive 600
comp-lzo
user openvpn
group openvpn
persist-tun
persist-key
verb 3
log-append /var/log/openvpn.log
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 10.8.0.1"

Yes...I made sure named was listening on 10.8.0.1

allow-query     { localhost; 192.168.10.0/24; 10.8.0.0/24;};
listen-on port 53 { 127.0.0.1; 192.168.10.1; 10.8.0.1;};

client.conf

client
proto udp
remote X.X.X.X
port 51194
dev tun
nobind
comp-lzo
verb 3

ip route show

default via X.X.0.1 dev eth0
10.8.0.0/24 via 10.8.0.2 dev tun0
10.8.0.2 dev tun0  proto kernel  scope link  src 10.8.0.1
X.X.0.0/19 dev eth0  proto kernel  scope link  src X.X.X.X
169.254.0.0/16 dev eth0  scope link  metric 1002
169.254.0.0/16 dev eth1  scope link  metric 1003
192.168.10.0/24 dev eth1  proto kernel  scope link  src 192.168.10.1

iptables -n -v -L

Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
   29  2455 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
  716 38160 ACCEPT     all  --  eth1  *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  tun0   *       0.0.0.0/0            0.0.0.0/0
   37 13983 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     udp  --  eth0   *       0.0.0.0/0            X.X.X.X         udp dpt:1194
    2   770 DROP  all  --  eth0   *       0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy ACCEPT 227 packets, 81683 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 1098 packets, 1506K bytes)
 pkts bytes target     prot opt in     out     source               destination

I would just like to be able to access various services from my Android phone, with everything going through the VPN. Services include, but not limited to, MediaTomb, SSH, and HTTP/S. It would be even better if I could hit those using the existing DNS entries, which all point to the LAN IP 192.168.10.1. The funny part is, I originally had this working. Meaning, the above configuration was working just fine. When I would connect from my Android phone from the local WiFi hotspot area (cough cough, local pub, cough cough), I could ping 192.168.10.1 (aka ssh.mydomain.com), and I would get a reply. I opened Chrome on the phone and went to https://ssh.mydomain.com and my web app launched. When I launched Avia (mediaplayer), it still didn't see MediaTomb, but I figured that was a broadcast issue, so just fired MediaTomb up on the tun0 interface, and then Avia saw both MediaTomb services (for some odd reason, it saw both the tun0 and the eth1 instances, but only when the tun0 instance was running).

Now, for some unknown reason, I can no longer get a reply when I ping 192.168.10.1. I can still ping 10.8.0.1, but not eth1 interface. I also can not get to MediaTomb. I can still SSH to 10.8.0.1, but it seems like all routes to 192.168.10.1 have stopped. Which, obviously, means I can not get to any of the other desktops in my house: 192.168.10.5, 192.168.10.10, etc. Very confused, as this was working just fine. I didn't change anything, so not sure what/why this just stopped working.

Am I missing something simple?

TIA,
-Lup

Traffic

Lupine wroteAm I missing something simple?

Why not use --server in the server config ?

Lupine

That's already in there:

mode server

Traffic

--mode server is not the same as --server and as such your config is not complete.

See --server in The Manual v23x

maikcat

--server network netmask
A helper directive designed to simplify the configuration of OpenVPN's server mode. This directive will set up an OpenVPN server which will allocate addresses to clients out of the given network/netmask. The server itself will take the ".1" address of the given network for use as the server-side endpoint of the local TUN/TAP interface.

For example, --server 10.8.0.0 255.255.255.0 expands as follows:

mode server
tls-server
push "topology [topology]"

if dev tun AND (topology == net30 OR topology == p2p):
ifconfig 10.8.0.1 10.8.0.2
if !nopool:
ifconfig-pool 10.8.0.4 10.8.0.251
route 10.8.0.0 255.255.255.0
if client-to-client:
push "route 10.8.0.0 255.255.255.0"
else if topology == net30:
push "route 10.8.0.1"

if dev tap OR (dev tun AND topology == subnet):
ifconfig 10.8.0.1 255.255.255.0
if !nopool:
ifconfig-pool 10.8.0.2 10.8.0.254 255.255.255.0
push "route-gateway 10.8.0.1"

Lupine

Updated server.conf

port 1194
proto udp
dev tun
multihome
tls-server 
ca keys/ca.crt
cert keys/lup64.crt
key keys/lup64.key
dh keys/dh1024.pem
mode server
server 10.8.0.0 255.255.255.0
ifconfig 10.8.0.1 10.8.0.2
route 10.8.0.0 255.255.255.0
keepalive 10 60
inactive 600
comp-lzo
user openvpn
group openvpn
persist-tun
persist-key
verb 3
log-append /var/log/openvpn.log
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 10.8.0.1"

With "server" added in, I had to remove the "ifconfig-pool 10.8.0.4 10.8.0.255", per the documentation/log file. Unfortunately, I am still not able to ping the internal 192.168.10.1 interface. Must be something else.

Traffic

Lupine wroteper the documentation/log file. Unfortunately, I am still not able to ping the internal 192.168.10.1 interface. Must be something else.

did you check this ?
HOWTO: Expanding the scope of the VPN to include additional machines

Lupine

Yes, I have tried multiple variations of:

push "route 192.168.10.0 255.255.255.0"

...none of which are working. This is so strange, as this was working perfectly fine with the above/original configuration, and then it just stopped. So puzzled. :?

Traffic

Did you check your logs for errors ?

Lupine

Yes, but there are no errors. I've tailed the log file, starting from a clean empty log file, while restarting the OpenVPN service and having the client (phone) connect. There are no errors. In fact, the log files look pretty much the same from when this was originally working, to when this stopped working, and even recently with the additional changes provided in this post.

maikcat

did you enabled ip forwarding?

also remove these from your server config..

mode server
ifconfig 10.8.0.1 10.8.0.2
route 10.8.0.0 255.255.255.0

can you also post the output of

iptables -L -t nat -v

if you disable your firewall for testing, problem persists?

Michael.

Lupine

maikcat wrotedid you enabled ip forwarding?

Yes, I have this at the top of my firewall script:

echo "1" > /proc/sys/net/ipv4/ip_forward
echo "1" > /proc/sys/net/ipv4/ip_dynaddr

Here is the updated server.conf

port 1194
proto udp
dev tun
multihome
tls-server 
ca keys/ca.crt
cert keys/lup64.crt
key keys/lup64.key
dh keys/dh1024.pem
server 10.8.0.0 255.255.255.0
keepalive 10 60
inactive 600
comp-lzo
user openvpn
group openvpn
persist-tun
persist-key
verb 3
log-append /var/log/openvpn.log
push "redirect-gateway def1 bypass-dhcp"
push "route 192.168.10.0 255.255.255.0"
push "dhcp-option DNS 10.8.0.1"

iptables -L -t nat -v

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 3 packets, 202 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 3 packets, 202 bytes)
 pkts bytes target     prot opt in     out     source               destination

maikcat wroteif you disable your firewall for testing, problem persists?

Problem persists.

maikcat

Now, for some unknown reason, I can no longer get a reply when I ping 192.168.10.1.
I can still ping 10.8.0.1, but not eth1 interface. I also can not get to MediaTomb.
I can still SSH to 10.8.0.1, but it seems like all routes to 192.168.10.1 have stopped.
Which, obviously, means I can not get to any of the other desktops in my house: 192.168.10.5, 192.168.10.10, etc.
Very confused, as this was working just fine. I didn't change anything, so not sure what/why this just stopped working.

with firewall down and ip forwarding enabled i believe the problem is routing related...

can you please post the output of

netstat -nr

on your client before & after vpn is up?
also what shows a tracert to 192.168.10.1 ?

also for consistency can you please repost the current configs used?

Michael.

Lupine

maikcat wrotewith firewall down and ip forwarding enabled i believe the problem is routing related...

That's what I was thinking from the beginning, but very confused as to why it was working, and then just stopped. I didn't change or add anything special for routing, initially it "just worked". Also, I was under the impression, that with this being a multihome configuration, I wouldn't have to add anything special for the routing, as the tun 10.8.0.1 and eth1 192.168.10.1 interfaces should be able to route to each other without additional configuration.

I am not seeing the 192.168.10.x routes getting pushed to the client. Keep in mind, the client is an Android phone. The netstat command didn't produce the desirable output, so I used the "ip route show" command within ConnectBot.
ip route show #from phone

default via X.X.X.101 dev rmnet1
10.8.0.4/30 dev tun0  proto kernel  scope link  src 10.8.0.6
 
X.X.X.96/29 dev rmnet1  proto kernel  scope link  src X.X.X.100
X.X.X.101 dev rmnet1  scope link

...X.X.X.101 being the phone's ISP IP.

Obviously, with those routes, it is defaulting to the phone's WiFi or Mobile connection, so tracerouting to 192.168.10.1 is not going to the VPN connection, and getting lost on the Internet. Seems to me, like the 'push "route 192.168.10.0 255.255.255.0"' is not working. Although, in the log file I do see it configured:

'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,route 192.168.10.0 255.255.255.0,dhcp-option DNS 10.8.0.1,route 10.8.0.1,topology net30,ping 10,ping-restart 60,ifconfig 10.8.0.6 10.8.0.5' (status=1)

And on the phone's log file, I see no error with the related configuration:

[route][192.168.10.0][255.255.255.0]

Below are all the update configs.

server.conf

port 1194
proto udp
dev tun
multihome
tls-server 
ca keys/ca.crt
cert keys/lup64.crt
key keys/lup64.key
dh keys/dh1024.pem
server 10.8.0.0 255.255.255.0
keepalive 10 60
inactive 600
comp-lzo
user openvpn
group openvpn
persist-tun
persist-key
verb 3
log-append /var/log/openvpn.log
push "redirect-gateway def1 bypass-dhcp"
push "route 192.168.10.0 255.255.255.0"
push "dhcp-option DNS 10.8.0.1"

client.conf

client
proto udp
remote X.X.X.X
port 1194
dev tun
nobind
comp-lzo
verb 3

ip route show #for server

default via X.X.0.1 dev eth0
10.8.0.0/24 via 10.8.0.2 dev tun0
10.8.0.2 dev tun0  proto kernel  scope link  src 10.8.0.1
X.X.0.0/19 dev eth0  proto kernel  scope link  src X.X.X.X
169.254.0.0/16 dev eth0  scope link  metric 1002
169.254.0.0/16 dev eth1  scope link  metric 1003
192.168.10.0/24 dev eth1  proto kernel  scope link  src 192.168.10.1

firewall has forwarding enabled:

echo "1" > /proc/sys/net/ipv4/ip_forward
echo "1" > /proc/sys/net/ipv4/ip_dynaddr

iptables -n -v -L

Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
   29  2455 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
  716 38160 ACCEPT     all  --  eth1  *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  tun0   *       0.0.0.0/0            0.0.0.0/0
   37 13983 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     udp  --  eth0   *       0.0.0.0/0            X.X.X.X         udp dpt:1194
    2   770 DROP  all  --  eth0   *       0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy ACCEPT 227 packets, 81683 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 1098 packets, 1506K bytes)
 pkts bytes target     prot opt in     out     source               destination

iptables -L -t nat -v

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 3 packets, 202 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 3 packets, 202 bytes)
 pkts bytes target     prot opt in     out     source               destination

Traffic

You say

Lupine wroteI can still SSH to 10.8.0.1, but it seems like all routes to 192.168.10.1 have stopped

Do hosts in 192.168.10.0/24 have a route for 10.8.0.0/24 ?

Lupine

No, none of the devices on the 192.168.10.0/24 side can get to my phone when connected to the VPN.

Traffic

Traffic wroteYou say
Lupine wroteI can still SSH to 10.8.0.1, but it seems like all routes to 192.168.10.1 have stopped
Do hosts in 192.168.10.0/24 have a route for 10.8.0.0/24 ?

Lupine wroteNo, none of the devices on the 192.168.10.0/24 side can get to my phone when connected to the VPN.

It appears, you do not understand the question ...

Have you read all of this howto:
HOWTO: Expanding the scope of the VPN to include additional machines

* See this section *

HOWTO wroteThe last step, and one that is often forgotten ...

Lupine

OK, I guess I should have checked this from the beginning, I just didn't access to a laptop, as readily available as I did my phone.

I took an old AsusEEE and installed Fedora on it. Configured it using the same client setup (just different certs) that I did for the Android phone. Went to a local WiFi hotspot, and everything worked perfectly fine with my current setup. The Fedora EEE connected right away to my OpenVPN server, and I could instantly access everything on my 192.168.10.0 network.

This proves, at least I feel it does, that it is something wrong/different on the Android OpenVPN Connect version, and not the server configuration/setup/routing as initially thought. I even tried to switch the phone to Airplane mode, and connected to the same WiFi hotspot, but it still would not access the 192.168.10.0 network. It is not pushing the correct route information to the phone. This works correctly on the laptop, but just not the phone. The version of OpenVPN Connect is 1.1.14 (build 56).

It's up to the moderators, but I would say that this topic should get moved to the "OpenVPN Connect (Android)" forum, as this is not a Server Configuration issue, it's a phone issue.

Lupine

....and it seems this is already a known issue:
Not adding routes on Kitkat 4.4.2
https://forums.openvpn.net/topic14807.html

Sorry for wasting your time. Thanks for help and guidance. At least I know my server is solid, and that's an important step.

Traffic

* Topic moved *

Lupine wroteSorry for wasting your time. Thanks for help and guidance

No problem .. you found the problem yourself ..
so thank you for letting us know the current situation.