OpenVPN different results on Windows 10 vs Ubuntu



  • Hi Guys,

    Me again :D

    I've run into quite a strange issue (again) and it's probably me (again) but I'm having a very hard time getting my Openvpn running the way I want.

    My config is pretty standard. I have an Openvpn server set up that I only want to allow to a certain host on the lan.

    In the IPv4 Local network(s) setting I have the host as 192.168.1.15/32
    Redirect gateway (force all client generated traffic through tunnel) is unticked.

    I've added a firewall rule that allows all traffic (like the default LAN rule) under the OpenVPN tab - This was done because I have another Openvpn server running which I want to have access to all clients on the LAN.

    When connecting to these VPN servers from Windows 10, everything is as expected. On the 1st server I only have access to the 1 client and cannot reach anything else. The 2nd server gives me full access to the LAN.

    However when connecting from my Ubuntu machine to vpnserver1 I can pretty much reach any host on the LAN and it also seems that all my WAN traffic is being pushed through the VPN when checking icanhazip.com - This is not the case in Windows.

    Could somebody perhaps enlighten me and point me in the right direction. As always, any feedback is much appreciated.



  • So check the OpenVPN client setting on Ubuntu. Maybe you thave set the default route to the VPN.

    The routes you push to the clients are no security feature!
    Any user who has admin privileges on his system is able to set the routes by himself and direct any traffic over the VPN.

    To control access to your server side networks add appropriate firewall rules to the OpenVPN interface. Since you have two servers, you will also have different tunnel subnets, which you can use as source in the rules to differ the users.



  • The routes you push to the clients are no security feature!
    Any user who has admin privileges on his system is able to set the routes by himself and direct any traffic over the VPN.

    As a general caveat I'd agree with that statement, but it got me thinking about the following scenario:

    Build a S2S SSL link using a suitably obscure OpenVPN tunnel IP 10.100.10.0/24

    On the Server, define the allowed local networks as 192.168.100.20/32 and 192.168.100.75/32.

    Are you suggesting a valid client could connect and define a route on their PC that would allow them to reach 192.168.100.100 over the OpenVPN link?  I don't see how it could connect.  If the link has been defined to only support two very small subnets, I'd expect OpenVPN to disregard traffic for a different subnet if it has no route information.

    Of course you would have to ensure that the .20 and .75 devices couldn't inadvertently reach .100 , but that's a potentially "internal" network issue.



  • Thanks for the reply viragomann,

    I will check out the firewall  rules. I was just curious why this works on Windows and not Ubuntu from the client-side. @divsys - this was my understanding as well (although not using site to site).  All clients on the vpn-subnet  are only allowed to connect to one host ip (/32). Work fine in Windows, but not Ubuntu. Thanks for the feedback guys.  :)



  • @divsys:

    Build a S2S SSL link using a suitably obscure OpenVPN tunnel IP 10.100.10.0/24

    On the Server, define the connec local networks as 192.168.100.20/32 and 192.168.100.75/32.

    Are you suggesting a valid client could connect and define a route on their PC that would allow them to reach 192.168.100.100 over the OpenVPN link?  I don't see how it could connect.

    No, in a S2S setup the VPN connection generally is established between two routers and the routes are set from one router to the other one.
    Changing routes on a client computer behind a router will take no effect in this situation.

    E.g. if a user in your example tries to set a route to 192.168.100.100 he could route it to the router which establishes the S2S VPN connection at best. In most cases, this will be default case anyway, cause it will be the default gateway on the clients computer. Since the router has no other defined route for this destination, it will direct the traffic to it's upstream gateway for his part, where the packets will be dropped, cause they are addressed to a private IP.
    So the clients are not able to access 192.168.100.100.

    The security issue with that only persists on an VPN access server.



  • No, in a S2S setup the VPN connection generally is established between two routers and the routes are set from one router to the other one.
    Changing routes on a client computer behind a router will take no effect in this situation.

    OK fully agree here, the router <-> router link provides "a layer of insulation" the client can't see through and all is well.

    Now what happens if we do the same exercise but setup a Remote Access server instead?
    The client is now a PC connecting directly to the OpenVPN server, but if that server only knows how to route two specific subnets to the client how does anything else get through?



  • A VPN server can never absolutely control the routes on the client. The routes can be set by anyone who has admin privileges. So you can set the default route to the VPN server, while the server pushes only one host to the client. If the access isn't restricted by firewall rules the client can reach any host behind by manipulate his routes.

    The push route option of OpenVPN and other VPN systems is just feature to ease the clients access to the server side network.
    As Tweebeenvis' Ubuntu host shows that's no security feature.



  • OpenVPN's concept of client set up is flawed but it's not completely the fault of OpenVPN. The OpenVPN server can never know (if we assume completely automated set up without manual overrides) if the settings it's pushing to the client are sane for the particular client, it can only hope they are.



  • I agree the OpenVPN tools to control client access are limited, but that doesn't mean they can't be effective.

    A VPN server can never absolutely control the routes on the client. The routes can be set by anyone who has admin privileges.

    This is true on the face of it, but a little misleading since it's missing one important addition:

    "Within the subnet(s) defined for the OpenVPN connection"

    Or to put it another way, if I define 192.168.100.0/28 as the allowed network within my 192.168.100.0/24 LAN for a client OpenVPN connection, there is no way for any connected client to have access to 192.168.100.75.

    I agree that's not the nicest way to secure connections, as it implies a different OVPN Server each time I want to a different section of my /24 subnet.

    It would be much nicer if I could securely specify the subnets allowed at the granularity of each client as they connect. But the current tools allow us to make secure connections if not as conveniently as we'd like.



  • @divsys:

    Or to put it another way, if I define 192.168.100.0/28 as the allowed network within my 192.168.100.0/24 LAN

    How will you do this??

    Not with the "Local Network/s" option in the OpenVPN server settings, do you? That's just for pushing routes, it's not for securing your internal network.

    @divsys:

    It would be much nicer if I could securely specify the subnets allowed at the granularity of each client as they connect.

    You can realise this with "client specific overrides" to allocate a specific tunnel address to a certain vpn client. Then you can use this tunnel address as source address in your firewall rules. It's a bit of work, but it's doable.