Client can't connect - Network is Unreachable

I'm trying to get my PIA account to connect via OpenVPN on one of my servers.  It's an Ubuntu 16.04 machine running headless.  I downloaded the OpenVPN config files but when I try to connect I get the following response...
Mon Apr 16 18:30:45 2018 UDPv4 link local: [undef]
Mon Apr 16 18:30:45 2018 UDPv4 link remote: [AF_INET]107.182.231.8:1198
Mon Apr 16 18:30:45 2018 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Mon Apr 16 18:30:45 2018 [93fcd5d49cad824cb0f914fa95535683] Peer Connection Initiated with [AF_INET]107.182.231.8:1198
Mon Apr 16 18:30:47 2018 TUN/TAP device tun0 opened
Mon Apr 16 18:30:47 2018 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Mon Apr 16 18:30:47 2018 /sbin/ip link set dev tun0 up mtu 1500
Mon Apr 16 18:30:47 2018 /sbin/ip addr add dev tun0 local 10.30.10.6 peer 10.30.10.5
RTNETLINK answers: Network is unreachable
Mon Apr 16 18:30:47 2018 ERROR: Linux route add command failed: external program exited with error status: 2
Mon Apr 16 18:30:47 2018 Initialization Sequence Completed
^CRTNETLINK answers: No such process
Mon Apr 16 18:30:49 2018 ERROR: Linux route delete command failed: external program exited with error status: 2
Mon Apr 16 18:30:49 2018 /sbin/ip addr del dev tun0 local 10.30.10.6 peer 10.30.10.5
Mon Apr 16 18:30:49 2018 SIGINT[hard,] received, process exiting

Not really sure what to do here.  If I leave this running without CTRL+Cing out of it, the tun0 is up and it has an internal IP on the 10.x.x.x subnet so it looks like it's sort of getting there, but it has no Internet access.

This is going through an Edgerouter Lite if that is relevant.  Not really any crazy configurations going on there, just a basic firewall setup.  My internal network is on a 192.168.x.x scheme.  I've already turned on net.ipv4.ip_forward = 1 in the sysctl file.  I've been digging all over for this but I have no idea what's going on.

Comments

  • wait.. where did you enable ip_forward?
  • /etc/sysctl.conf
  • *which device/system* ?
  • edited April 2018
    On the client system.  I don't know if it was necessary or useful I just found it in a post somewhere.  Obviously I have no access to the server because it's PIA, not mine.

    Does it need to be enabled on the router?
  • No. and no, not on your client system, either. found on what post where? it's not in any of the official "how to install" instructions the folks at PIA took pains to put together.
  • edited April 2018
    I mean, I understand it's not part of the official "How to install" instruction.  I tried those and it doesn't work, so I needed to look for solutions to my issue.  That was a solution that had worked for someone else via some searching.

    I have to assume the problem lies either in my router/firewall settings or somewhere on my OS, but the OS is basically a fresh install of Ubuntu server 16.04 so the latter seems unlikely.  The UFW firewall on the server is not even active and the only other networking setting I've modified is to give it a static IP on my home network.

    So what could cause openvpn to pick up an IP on the VPN but not have any connection?  See below - it is creating the tunnel and getting an IP on the 10.x.x.x scheme but it won't do anything else.  Seems like all packets are being dropped.  That mask also looks wrong, but it's not something I get to set so I'm not sure what to do about it.

    tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
              inet addr:10.8.11.6  P-t-P:10.8.11.5  Mask:255.255.255.255
              UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
              RX packets:0 errors:0 dropped:0 overruns:0 frame:0
              TX packets:3340736 errors:0 dropped:3342847 overruns:0 carrier:0
              collisions:0 txqueuelen:100
              RX bytes:0 (0.0 B)  TX bytes:5008330807 (5.0 GB)
  • just because someone who doesn't quite know how they fixed a thing says it has something to do with ip_forward, it doesn't mean that's true.  don't. because that's not what's going on. okay?

    since you're checking one-thing-at-a-time (that's an excellent strategy), when the VPN is up:
    1. make sure your LAN interface has a reasonable IP address (that's implied by the next item)
    2. make sure you have a tunnel interface with a reasonable IP configuration (you checked that. consider #1 checked, too, now)
    3. make sure your routing table has sane entries ( route -n  and/or ip route )
    4. make sure your /etc/resolv.conf file has sane entries
Sign In or Register to comment.