Adding a route to make server directly accessible over VPN, for specific subnet?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
1
down vote

favorite












I have a Linux machine on a segregated network that I VPN into. When I VPN in, I get assigned a virtual IP by the VPN server like 192.168.251.x



I've found that when I VPN in, I can RDP to Windows boxes no problem. Ping, http, rdp, etc.. all work. However, the Linux box is not immediately accessible. In fact, I have to first RDP onto a machine already on that segregated network, and then I can ssh into the Linux box.



This tells me the Linux box is only accepting traffic from devices already on its native subnet, and that I need to tell it to accept traffic from the virtual VPN subnet from which external devices will be originating.



I've tried this rule:



sudo iptables -A INPUT -p tcp -s 192.168.251.0/24 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT


Where 192.168.251.0/24 is the virtual VPN subnet. But I still cannot ping the Linux box yet from my connected host machine. So either I added the wrong rule, or added it incorrectly. Any tips/guidance?



user@HOST:~> uname -a 
Linux HOST 3.0.51-0.7.9-default #1 SMP Thu Nov 29 22:12:17 UTC 2012 (f3be9d0) x86_64 x86_64 x86_64 GNU/Linux

user@HOST:~> cat /proc/version Linux
version 3.0.51-0.7.9-default (geeko@buildhost) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP Thu Nov 29 22:12:17 UTC 2012 (f3be9d0)


Am I adding the wrong rule, or missing a rule?



EDIT:



My current iptables:



Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- 192.168.251.0/24 anywhere ctstate NEW,ESTABLISHED


Also, a packet capture of icmp and http/s traffic shows traffic from my VPN client going to the Linux machine, but never any return traffic from the Linux machine. Not even a reply with "invalid XXX" or anything. This indicates that traffic is getting dropped if I'm not mistaken.



EDIT:



user@HOST:~> ip route sh
127.0.0.0/8 dev lo scope link
169.254.0.0/16 dev eth0 scope link
192.168.20.0/24 dev eth0 proto kernel scope link src 192.168.20.219

user@HOST:~> sudo iptables --list
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- anywhere 192.168.251.0/24 ctstate ESTABLISHED


EDIT:



Solution for me was to run:



sudo ip route add default via 192.168.20.1


Then I was able to ping and telnet to the box directly via VPN.







share|improve this question






















  • Can you look at logs on the Linux box?  Run a sniffer (e.g., tcpdump or Wireshark) on it to determine what network traffic it is seeing?
    – G-Man
    Mar 14 at 21:49










  • Yep. Did a capture and interestingly I can only see traffic going 1 way. From my VPN ip to the linux machine. I see all 4 of my icmp packets, and my https requests. But nothing ever comes back from the linux machine. I know it's not a firewall rule because traffic to other machines on the network makes it through just fine. It's like this machine is blocking/dropping/rejecting my traffic entirely.
    – Tikiyetti
    Mar 14 at 22:09










  • Sounds like a routing issue on your Linux box. Does it know where to send the return packets back to your client? ip route sh could help debug this.
    – user234931
    Mar 14 at 23:05










  • I'm almost certain it's a routing issue. I wasn't sure however if I needed to define an outbound rule as well.So I added an outbound rule in iptables too. Updated the ticket with requested information.
    – Tikiyetti
    Mar 14 at 23:38










  • Actually, my bad. I did read it wrong. There is nothing about the 192.168.251.x subnet. The subnet listed from the command (192.168.20.0/24) is the native subnet. Not the VPN one. So it doesn't actually have anything regarding the VPN subnet.
    – Tikiyetti
    Mar 14 at 23:55














up vote
1
down vote

favorite












I have a Linux machine on a segregated network that I VPN into. When I VPN in, I get assigned a virtual IP by the VPN server like 192.168.251.x



I've found that when I VPN in, I can RDP to Windows boxes no problem. Ping, http, rdp, etc.. all work. However, the Linux box is not immediately accessible. In fact, I have to first RDP onto a machine already on that segregated network, and then I can ssh into the Linux box.



This tells me the Linux box is only accepting traffic from devices already on its native subnet, and that I need to tell it to accept traffic from the virtual VPN subnet from which external devices will be originating.



I've tried this rule:



sudo iptables -A INPUT -p tcp -s 192.168.251.0/24 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT


Where 192.168.251.0/24 is the virtual VPN subnet. But I still cannot ping the Linux box yet from my connected host machine. So either I added the wrong rule, or added it incorrectly. Any tips/guidance?



user@HOST:~> uname -a 
Linux HOST 3.0.51-0.7.9-default #1 SMP Thu Nov 29 22:12:17 UTC 2012 (f3be9d0) x86_64 x86_64 x86_64 GNU/Linux

user@HOST:~> cat /proc/version Linux
version 3.0.51-0.7.9-default (geeko@buildhost) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP Thu Nov 29 22:12:17 UTC 2012 (f3be9d0)


Am I adding the wrong rule, or missing a rule?



EDIT:



My current iptables:



Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- 192.168.251.0/24 anywhere ctstate NEW,ESTABLISHED


Also, a packet capture of icmp and http/s traffic shows traffic from my VPN client going to the Linux machine, but never any return traffic from the Linux machine. Not even a reply with "invalid XXX" or anything. This indicates that traffic is getting dropped if I'm not mistaken.



EDIT:



user@HOST:~> ip route sh
127.0.0.0/8 dev lo scope link
169.254.0.0/16 dev eth0 scope link
192.168.20.0/24 dev eth0 proto kernel scope link src 192.168.20.219

user@HOST:~> sudo iptables --list
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- anywhere 192.168.251.0/24 ctstate ESTABLISHED


EDIT:



Solution for me was to run:



sudo ip route add default via 192.168.20.1


Then I was able to ping and telnet to the box directly via VPN.







share|improve this question






















  • Can you look at logs on the Linux box?  Run a sniffer (e.g., tcpdump or Wireshark) on it to determine what network traffic it is seeing?
    – G-Man
    Mar 14 at 21:49










  • Yep. Did a capture and interestingly I can only see traffic going 1 way. From my VPN ip to the linux machine. I see all 4 of my icmp packets, and my https requests. But nothing ever comes back from the linux machine. I know it's not a firewall rule because traffic to other machines on the network makes it through just fine. It's like this machine is blocking/dropping/rejecting my traffic entirely.
    – Tikiyetti
    Mar 14 at 22:09










  • Sounds like a routing issue on your Linux box. Does it know where to send the return packets back to your client? ip route sh could help debug this.
    – user234931
    Mar 14 at 23:05










  • I'm almost certain it's a routing issue. I wasn't sure however if I needed to define an outbound rule as well.So I added an outbound rule in iptables too. Updated the ticket with requested information.
    – Tikiyetti
    Mar 14 at 23:38










  • Actually, my bad. I did read it wrong. There is nothing about the 192.168.251.x subnet. The subnet listed from the command (192.168.20.0/24) is the native subnet. Not the VPN one. So it doesn't actually have anything regarding the VPN subnet.
    – Tikiyetti
    Mar 14 at 23:55












up vote
1
down vote

favorite









up vote
1
down vote

favorite











I have a Linux machine on a segregated network that I VPN into. When I VPN in, I get assigned a virtual IP by the VPN server like 192.168.251.x



I've found that when I VPN in, I can RDP to Windows boxes no problem. Ping, http, rdp, etc.. all work. However, the Linux box is not immediately accessible. In fact, I have to first RDP onto a machine already on that segregated network, and then I can ssh into the Linux box.



This tells me the Linux box is only accepting traffic from devices already on its native subnet, and that I need to tell it to accept traffic from the virtual VPN subnet from which external devices will be originating.



I've tried this rule:



sudo iptables -A INPUT -p tcp -s 192.168.251.0/24 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT


Where 192.168.251.0/24 is the virtual VPN subnet. But I still cannot ping the Linux box yet from my connected host machine. So either I added the wrong rule, or added it incorrectly. Any tips/guidance?



user@HOST:~> uname -a 
Linux HOST 3.0.51-0.7.9-default #1 SMP Thu Nov 29 22:12:17 UTC 2012 (f3be9d0) x86_64 x86_64 x86_64 GNU/Linux

user@HOST:~> cat /proc/version Linux
version 3.0.51-0.7.9-default (geeko@buildhost) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP Thu Nov 29 22:12:17 UTC 2012 (f3be9d0)


Am I adding the wrong rule, or missing a rule?



EDIT:



My current iptables:



Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- 192.168.251.0/24 anywhere ctstate NEW,ESTABLISHED


Also, a packet capture of icmp and http/s traffic shows traffic from my VPN client going to the Linux machine, but never any return traffic from the Linux machine. Not even a reply with "invalid XXX" or anything. This indicates that traffic is getting dropped if I'm not mistaken.



EDIT:



user@HOST:~> ip route sh
127.0.0.0/8 dev lo scope link
169.254.0.0/16 dev eth0 scope link
192.168.20.0/24 dev eth0 proto kernel scope link src 192.168.20.219

user@HOST:~> sudo iptables --list
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- anywhere 192.168.251.0/24 ctstate ESTABLISHED


EDIT:



Solution for me was to run:



sudo ip route add default via 192.168.20.1


Then I was able to ping and telnet to the box directly via VPN.







share|improve this question














I have a Linux machine on a segregated network that I VPN into. When I VPN in, I get assigned a virtual IP by the VPN server like 192.168.251.x



I've found that when I VPN in, I can RDP to Windows boxes no problem. Ping, http, rdp, etc.. all work. However, the Linux box is not immediately accessible. In fact, I have to first RDP onto a machine already on that segregated network, and then I can ssh into the Linux box.



This tells me the Linux box is only accepting traffic from devices already on its native subnet, and that I need to tell it to accept traffic from the virtual VPN subnet from which external devices will be originating.



I've tried this rule:



sudo iptables -A INPUT -p tcp -s 192.168.251.0/24 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT


Where 192.168.251.0/24 is the virtual VPN subnet. But I still cannot ping the Linux box yet from my connected host machine. So either I added the wrong rule, or added it incorrectly. Any tips/guidance?



user@HOST:~> uname -a 
Linux HOST 3.0.51-0.7.9-default #1 SMP Thu Nov 29 22:12:17 UTC 2012 (f3be9d0) x86_64 x86_64 x86_64 GNU/Linux

user@HOST:~> cat /proc/version Linux
version 3.0.51-0.7.9-default (geeko@buildhost) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP Thu Nov 29 22:12:17 UTC 2012 (f3be9d0)


Am I adding the wrong rule, or missing a rule?



EDIT:



My current iptables:



Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- 192.168.251.0/24 anywhere ctstate NEW,ESTABLISHED


Also, a packet capture of icmp and http/s traffic shows traffic from my VPN client going to the Linux machine, but never any return traffic from the Linux machine. Not even a reply with "invalid XXX" or anything. This indicates that traffic is getting dropped if I'm not mistaken.



EDIT:



user@HOST:~> ip route sh
127.0.0.0/8 dev lo scope link
169.254.0.0/16 dev eth0 scope link
192.168.20.0/24 dev eth0 proto kernel scope link src 192.168.20.219

user@HOST:~> sudo iptables --list
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- anywhere 192.168.251.0/24 ctstate ESTABLISHED


EDIT:



Solution for me was to run:



sudo ip route add default via 192.168.20.1


Then I was able to ping and telnet to the box directly via VPN.









share|improve this question













share|improve this question




share|improve this question








edited Mar 15 at 0:31

























asked Mar 14 at 20:42









Tikiyetti

83




83











  • Can you look at logs on the Linux box?  Run a sniffer (e.g., tcpdump or Wireshark) on it to determine what network traffic it is seeing?
    – G-Man
    Mar 14 at 21:49










  • Yep. Did a capture and interestingly I can only see traffic going 1 way. From my VPN ip to the linux machine. I see all 4 of my icmp packets, and my https requests. But nothing ever comes back from the linux machine. I know it's not a firewall rule because traffic to other machines on the network makes it through just fine. It's like this machine is blocking/dropping/rejecting my traffic entirely.
    – Tikiyetti
    Mar 14 at 22:09










  • Sounds like a routing issue on your Linux box. Does it know where to send the return packets back to your client? ip route sh could help debug this.
    – user234931
    Mar 14 at 23:05










  • I'm almost certain it's a routing issue. I wasn't sure however if I needed to define an outbound rule as well.So I added an outbound rule in iptables too. Updated the ticket with requested information.
    – Tikiyetti
    Mar 14 at 23:38










  • Actually, my bad. I did read it wrong. There is nothing about the 192.168.251.x subnet. The subnet listed from the command (192.168.20.0/24) is the native subnet. Not the VPN one. So it doesn't actually have anything regarding the VPN subnet.
    – Tikiyetti
    Mar 14 at 23:55
















  • Can you look at logs on the Linux box?  Run a sniffer (e.g., tcpdump or Wireshark) on it to determine what network traffic it is seeing?
    – G-Man
    Mar 14 at 21:49










  • Yep. Did a capture and interestingly I can only see traffic going 1 way. From my VPN ip to the linux machine. I see all 4 of my icmp packets, and my https requests. But nothing ever comes back from the linux machine. I know it's not a firewall rule because traffic to other machines on the network makes it through just fine. It's like this machine is blocking/dropping/rejecting my traffic entirely.
    – Tikiyetti
    Mar 14 at 22:09










  • Sounds like a routing issue on your Linux box. Does it know where to send the return packets back to your client? ip route sh could help debug this.
    – user234931
    Mar 14 at 23:05










  • I'm almost certain it's a routing issue. I wasn't sure however if I needed to define an outbound rule as well.So I added an outbound rule in iptables too. Updated the ticket with requested information.
    – Tikiyetti
    Mar 14 at 23:38










  • Actually, my bad. I did read it wrong. There is nothing about the 192.168.251.x subnet. The subnet listed from the command (192.168.20.0/24) is the native subnet. Not the VPN one. So it doesn't actually have anything regarding the VPN subnet.
    – Tikiyetti
    Mar 14 at 23:55















Can you look at logs on the Linux box?  Run a sniffer (e.g., tcpdump or Wireshark) on it to determine what network traffic it is seeing?
– G-Man
Mar 14 at 21:49




Can you look at logs on the Linux box?  Run a sniffer (e.g., tcpdump or Wireshark) on it to determine what network traffic it is seeing?
– G-Man
Mar 14 at 21:49












Yep. Did a capture and interestingly I can only see traffic going 1 way. From my VPN ip to the linux machine. I see all 4 of my icmp packets, and my https requests. But nothing ever comes back from the linux machine. I know it's not a firewall rule because traffic to other machines on the network makes it through just fine. It's like this machine is blocking/dropping/rejecting my traffic entirely.
– Tikiyetti
Mar 14 at 22:09




Yep. Did a capture and interestingly I can only see traffic going 1 way. From my VPN ip to the linux machine. I see all 4 of my icmp packets, and my https requests. But nothing ever comes back from the linux machine. I know it's not a firewall rule because traffic to other machines on the network makes it through just fine. It's like this machine is blocking/dropping/rejecting my traffic entirely.
– Tikiyetti
Mar 14 at 22:09












Sounds like a routing issue on your Linux box. Does it know where to send the return packets back to your client? ip route sh could help debug this.
– user234931
Mar 14 at 23:05




Sounds like a routing issue on your Linux box. Does it know where to send the return packets back to your client? ip route sh could help debug this.
– user234931
Mar 14 at 23:05












I'm almost certain it's a routing issue. I wasn't sure however if I needed to define an outbound rule as well.So I added an outbound rule in iptables too. Updated the ticket with requested information.
– Tikiyetti
Mar 14 at 23:38




I'm almost certain it's a routing issue. I wasn't sure however if I needed to define an outbound rule as well.So I added an outbound rule in iptables too. Updated the ticket with requested information.
– Tikiyetti
Mar 14 at 23:38












Actually, my bad. I did read it wrong. There is nothing about the 192.168.251.x subnet. The subnet listed from the command (192.168.20.0/24) is the native subnet. Not the VPN one. So it doesn't actually have anything regarding the VPN subnet.
– Tikiyetti
Mar 14 at 23:55




Actually, my bad. I did read it wrong. There is nothing about the 192.168.251.x subnet. The subnet listed from the command (192.168.20.0/24) is the native subnet. Not the VPN one. So it doesn't actually have anything regarding the VPN subnet.
– Tikiyetti
Mar 14 at 23:55










1 Answer
1






active

oldest

votes

















up vote
0
down vote



accepted










The Linux box is dropping the return packet since it has no valid route back to the VPN network.



Assuming your gateway is at 192.168.20.1, adding this as a default route on your Linux box will likely resolve your issue:



ip route add default via 192.168.20.1





share|improve this answer




















    Your Answer







    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "106"
    ;
    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: false,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );








     

    draft saved


    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f430260%2fadding-a-route-to-make-server-directly-accessible-over-vpn-for-specific-subnet%23new-answer', 'question_page');

    );

    Post as a guest






























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    0
    down vote



    accepted










    The Linux box is dropping the return packet since it has no valid route back to the VPN network.



    Assuming your gateway is at 192.168.20.1, adding this as a default route on your Linux box will likely resolve your issue:



    ip route add default via 192.168.20.1





    share|improve this answer
























      up vote
      0
      down vote



      accepted










      The Linux box is dropping the return packet since it has no valid route back to the VPN network.



      Assuming your gateway is at 192.168.20.1, adding this as a default route on your Linux box will likely resolve your issue:



      ip route add default via 192.168.20.1





      share|improve this answer






















        up vote
        0
        down vote



        accepted







        up vote
        0
        down vote



        accepted






        The Linux box is dropping the return packet since it has no valid route back to the VPN network.



        Assuming your gateway is at 192.168.20.1, adding this as a default route on your Linux box will likely resolve your issue:



        ip route add default via 192.168.20.1





        share|improve this answer












        The Linux box is dropping the return packet since it has no valid route back to the VPN network.



        Assuming your gateway is at 192.168.20.1, adding this as a default route on your Linux box will likely resolve your issue:



        ip route add default via 192.168.20.1






        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Mar 15 at 0:40









        user234931

        25615




        25615






















             

            draft saved


            draft discarded


























             


            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f430260%2fadding-a-route-to-make-server-directly-accessible-over-vpn-for-specific-subnet%23new-answer', 'question_page');

            );

            Post as a guest













































































            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Displaying single band from multi-band raster using QGIS

            How many registers does an x86_64 CPU actually have?