How to enable LAN access to OpenVPN clients











up vote
0
down vote

favorite












I have a server with 2 real NIC and 1 virtual NIC (tun0) created by OpenVPN.



eth0 is LAN - IP 192.168.2.1
eth1 is Internet - IP is public internet IP
tun0 is created by openvpn


What I need is that clients that connect to VPN server over eth1 will also get access to eth0 network, eg. will be able to connect to 192.168.2.21



This used to work in past until I rebooted the server and routing info got reset :/ I configured this couple years ago and forgot how I did that.



Routing table now looks like this:



Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default public gw 0.0.0.0 UG 0 0 0 eth1
public ip * 255.255.255.0 U 0 0 0 eth1
192.168.2.0 * 255.255.255.0 U 0 0 0 eth0
192.168.8.0 192.168.8.2 255.255.255.0 UG 0 0 0 tun0
192.168.8.2 * 255.255.255.255 UH 0 0 0 tun0


When I launch OpenVPN it tries to add route



Tue Oct 11 19:29:58 2016 /sbin/ip route add 192.168.2.0/24 via 192.168.8.2
RTNETLINK answers: File exists
Tue Oct 11 19:29:58 2016 ERROR: Linux route add command failed: external program exited with error status: 2


It however doesn't seem to be possible because it already exists. When I remove this route openVPN succeeds in adding but it's no longer possible for server to reach 192.168.2.0/24 network.



How can I make it work?



EDIT: yes, I have both IPv4 and IPv6 forwarding enabled










share|improve this question
























  • Your question isn’t entirely clear on what happens where: VPN server or client. Please clarify. Also, for this to work, all machines on the 192.168.2.0/24 network need to know that 192.168.8.0/24 (the VPN subnet, I assume) is reachable via 192.168.2.1. If 192.168.2.1 is not the default gateway, you should set up a route on the default gateway.
    – Daniel B
    Oct 12 '16 at 8:31












  • @DanielB this what I describe here is server, which is also a gateway itself, it's DNS, DHCP and router for LAN and it also hosts that 192.168.8.0 subnet for VPN. This all used to work until I rebooted it, so there is no problem on client side. VPN client already pushes route to client, the problem is that the VPN server doesn't seem to allow machines from 192.168.8.0 to access 192.168.2.0 network
    – Petr
    Oct 12 '16 at 11:14










  • You misunderstand: A route needs to exist both ways for packets to go through both ways. You can easily verify whether packets are received using Wireshark. // Also, you automatically get a route to the subnet of an adapter’s IP address. Always.
    – Daniel B
    Oct 12 '16 at 13:49















up vote
0
down vote

favorite












I have a server with 2 real NIC and 1 virtual NIC (tun0) created by OpenVPN.



eth0 is LAN - IP 192.168.2.1
eth1 is Internet - IP is public internet IP
tun0 is created by openvpn


What I need is that clients that connect to VPN server over eth1 will also get access to eth0 network, eg. will be able to connect to 192.168.2.21



This used to work in past until I rebooted the server and routing info got reset :/ I configured this couple years ago and forgot how I did that.



Routing table now looks like this:



Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default public gw 0.0.0.0 UG 0 0 0 eth1
public ip * 255.255.255.0 U 0 0 0 eth1
192.168.2.0 * 255.255.255.0 U 0 0 0 eth0
192.168.8.0 192.168.8.2 255.255.255.0 UG 0 0 0 tun0
192.168.8.2 * 255.255.255.255 UH 0 0 0 tun0


When I launch OpenVPN it tries to add route



Tue Oct 11 19:29:58 2016 /sbin/ip route add 192.168.2.0/24 via 192.168.8.2
RTNETLINK answers: File exists
Tue Oct 11 19:29:58 2016 ERROR: Linux route add command failed: external program exited with error status: 2


It however doesn't seem to be possible because it already exists. When I remove this route openVPN succeeds in adding but it's no longer possible for server to reach 192.168.2.0/24 network.



How can I make it work?



EDIT: yes, I have both IPv4 and IPv6 forwarding enabled










share|improve this question
























  • Your question isn’t entirely clear on what happens where: VPN server or client. Please clarify. Also, for this to work, all machines on the 192.168.2.0/24 network need to know that 192.168.8.0/24 (the VPN subnet, I assume) is reachable via 192.168.2.1. If 192.168.2.1 is not the default gateway, you should set up a route on the default gateway.
    – Daniel B
    Oct 12 '16 at 8:31












  • @DanielB this what I describe here is server, which is also a gateway itself, it's DNS, DHCP and router for LAN and it also hosts that 192.168.8.0 subnet for VPN. This all used to work until I rebooted it, so there is no problem on client side. VPN client already pushes route to client, the problem is that the VPN server doesn't seem to allow machines from 192.168.8.0 to access 192.168.2.0 network
    – Petr
    Oct 12 '16 at 11:14










  • You misunderstand: A route needs to exist both ways for packets to go through both ways. You can easily verify whether packets are received using Wireshark. // Also, you automatically get a route to the subnet of an adapter’s IP address. Always.
    – Daniel B
    Oct 12 '16 at 13:49













up vote
0
down vote

favorite









up vote
0
down vote

favorite











I have a server with 2 real NIC and 1 virtual NIC (tun0) created by OpenVPN.



eth0 is LAN - IP 192.168.2.1
eth1 is Internet - IP is public internet IP
tun0 is created by openvpn


What I need is that clients that connect to VPN server over eth1 will also get access to eth0 network, eg. will be able to connect to 192.168.2.21



This used to work in past until I rebooted the server and routing info got reset :/ I configured this couple years ago and forgot how I did that.



Routing table now looks like this:



Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default public gw 0.0.0.0 UG 0 0 0 eth1
public ip * 255.255.255.0 U 0 0 0 eth1
192.168.2.0 * 255.255.255.0 U 0 0 0 eth0
192.168.8.0 192.168.8.2 255.255.255.0 UG 0 0 0 tun0
192.168.8.2 * 255.255.255.255 UH 0 0 0 tun0


When I launch OpenVPN it tries to add route



Tue Oct 11 19:29:58 2016 /sbin/ip route add 192.168.2.0/24 via 192.168.8.2
RTNETLINK answers: File exists
Tue Oct 11 19:29:58 2016 ERROR: Linux route add command failed: external program exited with error status: 2


It however doesn't seem to be possible because it already exists. When I remove this route openVPN succeeds in adding but it's no longer possible for server to reach 192.168.2.0/24 network.



How can I make it work?



EDIT: yes, I have both IPv4 and IPv6 forwarding enabled










share|improve this question















I have a server with 2 real NIC and 1 virtual NIC (tun0) created by OpenVPN.



eth0 is LAN - IP 192.168.2.1
eth1 is Internet - IP is public internet IP
tun0 is created by openvpn


What I need is that clients that connect to VPN server over eth1 will also get access to eth0 network, eg. will be able to connect to 192.168.2.21



This used to work in past until I rebooted the server and routing info got reset :/ I configured this couple years ago and forgot how I did that.



Routing table now looks like this:



Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default public gw 0.0.0.0 UG 0 0 0 eth1
public ip * 255.255.255.0 U 0 0 0 eth1
192.168.2.0 * 255.255.255.0 U 0 0 0 eth0
192.168.8.0 192.168.8.2 255.255.255.0 UG 0 0 0 tun0
192.168.8.2 * 255.255.255.255 UH 0 0 0 tun0


When I launch OpenVPN it tries to add route



Tue Oct 11 19:29:58 2016 /sbin/ip route add 192.168.2.0/24 via 192.168.8.2
RTNETLINK answers: File exists
Tue Oct 11 19:29:58 2016 ERROR: Linux route add command failed: external program exited with error status: 2


It however doesn't seem to be possible because it already exists. When I remove this route openVPN succeeds in adding but it's no longer possible for server to reach 192.168.2.0/24 network.



How can I make it work?



EDIT: yes, I have both IPv4 and IPv6 forwarding enabled







networking openvpn






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Oct 12 '16 at 8:09

























asked Oct 11 '16 at 17:54









Petr

66621326




66621326












  • Your question isn’t entirely clear on what happens where: VPN server or client. Please clarify. Also, for this to work, all machines on the 192.168.2.0/24 network need to know that 192.168.8.0/24 (the VPN subnet, I assume) is reachable via 192.168.2.1. If 192.168.2.1 is not the default gateway, you should set up a route on the default gateway.
    – Daniel B
    Oct 12 '16 at 8:31












  • @DanielB this what I describe here is server, which is also a gateway itself, it's DNS, DHCP and router for LAN and it also hosts that 192.168.8.0 subnet for VPN. This all used to work until I rebooted it, so there is no problem on client side. VPN client already pushes route to client, the problem is that the VPN server doesn't seem to allow machines from 192.168.8.0 to access 192.168.2.0 network
    – Petr
    Oct 12 '16 at 11:14










  • You misunderstand: A route needs to exist both ways for packets to go through both ways. You can easily verify whether packets are received using Wireshark. // Also, you automatically get a route to the subnet of an adapter’s IP address. Always.
    – Daniel B
    Oct 12 '16 at 13:49


















  • Your question isn’t entirely clear on what happens where: VPN server or client. Please clarify. Also, for this to work, all machines on the 192.168.2.0/24 network need to know that 192.168.8.0/24 (the VPN subnet, I assume) is reachable via 192.168.2.1. If 192.168.2.1 is not the default gateway, you should set up a route on the default gateway.
    – Daniel B
    Oct 12 '16 at 8:31












  • @DanielB this what I describe here is server, which is also a gateway itself, it's DNS, DHCP and router for LAN and it also hosts that 192.168.8.0 subnet for VPN. This all used to work until I rebooted it, so there is no problem on client side. VPN client already pushes route to client, the problem is that the VPN server doesn't seem to allow machines from 192.168.8.0 to access 192.168.2.0 network
    – Petr
    Oct 12 '16 at 11:14










  • You misunderstand: A route needs to exist both ways for packets to go through both ways. You can easily verify whether packets are received using Wireshark. // Also, you automatically get a route to the subnet of an adapter’s IP address. Always.
    – Daniel B
    Oct 12 '16 at 13:49
















Your question isn’t entirely clear on what happens where: VPN server or client. Please clarify. Also, for this to work, all machines on the 192.168.2.0/24 network need to know that 192.168.8.0/24 (the VPN subnet, I assume) is reachable via 192.168.2.1. If 192.168.2.1 is not the default gateway, you should set up a route on the default gateway.
– Daniel B
Oct 12 '16 at 8:31






Your question isn’t entirely clear on what happens where: VPN server or client. Please clarify. Also, for this to work, all machines on the 192.168.2.0/24 network need to know that 192.168.8.0/24 (the VPN subnet, I assume) is reachable via 192.168.2.1. If 192.168.2.1 is not the default gateway, you should set up a route on the default gateway.
– Daniel B
Oct 12 '16 at 8:31














@DanielB this what I describe here is server, which is also a gateway itself, it's DNS, DHCP and router for LAN and it also hosts that 192.168.8.0 subnet for VPN. This all used to work until I rebooted it, so there is no problem on client side. VPN client already pushes route to client, the problem is that the VPN server doesn't seem to allow machines from 192.168.8.0 to access 192.168.2.0 network
– Petr
Oct 12 '16 at 11:14




@DanielB this what I describe here is server, which is also a gateway itself, it's DNS, DHCP and router for LAN and it also hosts that 192.168.8.0 subnet for VPN. This all used to work until I rebooted it, so there is no problem on client side. VPN client already pushes route to client, the problem is that the VPN server doesn't seem to allow machines from 192.168.8.0 to access 192.168.2.0 network
– Petr
Oct 12 '16 at 11:14












You misunderstand: A route needs to exist both ways for packets to go through both ways. You can easily verify whether packets are received using Wireshark. // Also, you automatically get a route to the subnet of an adapter’s IP address. Always.
– Daniel B
Oct 12 '16 at 13:49




You misunderstand: A route needs to exist both ways for packets to go through both ways. You can easily verify whether packets are received using Wireshark. // Also, you automatically get a route to the subnet of an adapter’s IP address. Always.
– Daniel B
Oct 12 '16 at 13:49










2 Answers
2






active

oldest

votes

















up vote
0
down vote













you'll need ip_forward set in the sysctl, and an accept line in the FORWARD table in iptables (which often defaults to ACCEPT anyhow)



http://www.ducea.com/2006/08/01/how-to-enable-ip-forwarding-in-linux/






share|improve this answer





















  • I already have that, that isn't the issue here.
    – Petr
    Oct 12 '16 at 8:08










  • yeah, you'll also need the masquerade line from that link.
    – Sirex
    Oct 12 '16 at 18:45










  • MASQUERADE is only needed when a fully routed setup is not possible. It is possible, so it shouldn’t be used.
    – Daniel B
    Oct 13 '16 at 11:23


















up vote
0
down vote













First, the necessary routes:




  • VPN clients need a route to 192.168.2.0/24, via your VPN gateway (presumably at 192.168.8.1 inside the virtual network)

  • Devices in 192.168.2.0/24 need a route to 192.168.8.0/24 – because it appears your VPN server resides on the default gateway, additional configuration is not required.


Then, the configuration. The specifics depend on the topology (net30/p2p or subnet), but it’s like this in general:



topology net30    
server 192.168.8.0 255.255.255.0

push "route 192.168.2.0 255.255.255.0"


I omitted all irrelevant (but nonetheless mandatory) options here. Do note however that the route is only pushed to clients. It must not be set on the server.



Since the client receives all necessary settings via push, no special configuration is needed.






share|improve this answer





















    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "3"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1133752%2fhow-to-enable-lan-access-to-openvpn-clients%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    0
    down vote













    you'll need ip_forward set in the sysctl, and an accept line in the FORWARD table in iptables (which often defaults to ACCEPT anyhow)



    http://www.ducea.com/2006/08/01/how-to-enable-ip-forwarding-in-linux/






    share|improve this answer





















    • I already have that, that isn't the issue here.
      – Petr
      Oct 12 '16 at 8:08










    • yeah, you'll also need the masquerade line from that link.
      – Sirex
      Oct 12 '16 at 18:45










    • MASQUERADE is only needed when a fully routed setup is not possible. It is possible, so it shouldn’t be used.
      – Daniel B
      Oct 13 '16 at 11:23















    up vote
    0
    down vote













    you'll need ip_forward set in the sysctl, and an accept line in the FORWARD table in iptables (which often defaults to ACCEPT anyhow)



    http://www.ducea.com/2006/08/01/how-to-enable-ip-forwarding-in-linux/






    share|improve this answer





















    • I already have that, that isn't the issue here.
      – Petr
      Oct 12 '16 at 8:08










    • yeah, you'll also need the masquerade line from that link.
      – Sirex
      Oct 12 '16 at 18:45










    • MASQUERADE is only needed when a fully routed setup is not possible. It is possible, so it shouldn’t be used.
      – Daniel B
      Oct 13 '16 at 11:23













    up vote
    0
    down vote










    up vote
    0
    down vote









    you'll need ip_forward set in the sysctl, and an accept line in the FORWARD table in iptables (which often defaults to ACCEPT anyhow)



    http://www.ducea.com/2006/08/01/how-to-enable-ip-forwarding-in-linux/






    share|improve this answer












    you'll need ip_forward set in the sysctl, and an accept line in the FORWARD table in iptables (which often defaults to ACCEPT anyhow)



    http://www.ducea.com/2006/08/01/how-to-enable-ip-forwarding-in-linux/







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Oct 11 '16 at 20:07









    Sirex

    9,68343252




    9,68343252












    • I already have that, that isn't the issue here.
      – Petr
      Oct 12 '16 at 8:08










    • yeah, you'll also need the masquerade line from that link.
      – Sirex
      Oct 12 '16 at 18:45










    • MASQUERADE is only needed when a fully routed setup is not possible. It is possible, so it shouldn’t be used.
      – Daniel B
      Oct 13 '16 at 11:23


















    • I already have that, that isn't the issue here.
      – Petr
      Oct 12 '16 at 8:08










    • yeah, you'll also need the masquerade line from that link.
      – Sirex
      Oct 12 '16 at 18:45










    • MASQUERADE is only needed when a fully routed setup is not possible. It is possible, so it shouldn’t be used.
      – Daniel B
      Oct 13 '16 at 11:23
















    I already have that, that isn't the issue here.
    – Petr
    Oct 12 '16 at 8:08




    I already have that, that isn't the issue here.
    – Petr
    Oct 12 '16 at 8:08












    yeah, you'll also need the masquerade line from that link.
    – Sirex
    Oct 12 '16 at 18:45




    yeah, you'll also need the masquerade line from that link.
    – Sirex
    Oct 12 '16 at 18:45












    MASQUERADE is only needed when a fully routed setup is not possible. It is possible, so it shouldn’t be used.
    – Daniel B
    Oct 13 '16 at 11:23




    MASQUERADE is only needed when a fully routed setup is not possible. It is possible, so it shouldn’t be used.
    – Daniel B
    Oct 13 '16 at 11:23












    up vote
    0
    down vote













    First, the necessary routes:




    • VPN clients need a route to 192.168.2.0/24, via your VPN gateway (presumably at 192.168.8.1 inside the virtual network)

    • Devices in 192.168.2.0/24 need a route to 192.168.8.0/24 – because it appears your VPN server resides on the default gateway, additional configuration is not required.


    Then, the configuration. The specifics depend on the topology (net30/p2p or subnet), but it’s like this in general:



    topology net30    
    server 192.168.8.0 255.255.255.0

    push "route 192.168.2.0 255.255.255.0"


    I omitted all irrelevant (but nonetheless mandatory) options here. Do note however that the route is only pushed to clients. It must not be set on the server.



    Since the client receives all necessary settings via push, no special configuration is needed.






    share|improve this answer

























      up vote
      0
      down vote













      First, the necessary routes:




      • VPN clients need a route to 192.168.2.0/24, via your VPN gateway (presumably at 192.168.8.1 inside the virtual network)

      • Devices in 192.168.2.0/24 need a route to 192.168.8.0/24 – because it appears your VPN server resides on the default gateway, additional configuration is not required.


      Then, the configuration. The specifics depend on the topology (net30/p2p or subnet), but it’s like this in general:



      topology net30    
      server 192.168.8.0 255.255.255.0

      push "route 192.168.2.0 255.255.255.0"


      I omitted all irrelevant (but nonetheless mandatory) options here. Do note however that the route is only pushed to clients. It must not be set on the server.



      Since the client receives all necessary settings via push, no special configuration is needed.






      share|improve this answer























        up vote
        0
        down vote










        up vote
        0
        down vote









        First, the necessary routes:




        • VPN clients need a route to 192.168.2.0/24, via your VPN gateway (presumably at 192.168.8.1 inside the virtual network)

        • Devices in 192.168.2.0/24 need a route to 192.168.8.0/24 – because it appears your VPN server resides on the default gateway, additional configuration is not required.


        Then, the configuration. The specifics depend on the topology (net30/p2p or subnet), but it’s like this in general:



        topology net30    
        server 192.168.8.0 255.255.255.0

        push "route 192.168.2.0 255.255.255.0"


        I omitted all irrelevant (but nonetheless mandatory) options here. Do note however that the route is only pushed to clients. It must not be set on the server.



        Since the client receives all necessary settings via push, no special configuration is needed.






        share|improve this answer












        First, the necessary routes:




        • VPN clients need a route to 192.168.2.0/24, via your VPN gateway (presumably at 192.168.8.1 inside the virtual network)

        • Devices in 192.168.2.0/24 need a route to 192.168.8.0/24 – because it appears your VPN server resides on the default gateway, additional configuration is not required.


        Then, the configuration. The specifics depend on the topology (net30/p2p or subnet), but it’s like this in general:



        topology net30    
        server 192.168.8.0 255.255.255.0

        push "route 192.168.2.0 255.255.255.0"


        I omitted all irrelevant (but nonetheless mandatory) options here. Do note however that the route is only pushed to clients. It must not be set on the server.



        Since the client receives all necessary settings via push, no special configuration is needed.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Oct 13 '16 at 18:08









        Daniel B

        32.9k75986




        32.9k75986






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Super User!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1133752%2fhow-to-enable-lan-access-to-openvpn-clients%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            AnyDesk - Fatal Program Failure

            How to calibrate 16:9 built-in touch-screen to a 4:3 resolution?

            QoS: MAC-Priority for clients behind a repeater