Adding a route to make server directly accessible over VPN, for specific subnet?
Clash 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.
iptables openvpn route
 |Â
show 2 more comments
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.
iptables openvpn route
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
 |Â
show 2 more comments
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.
iptables openvpn route
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.
iptables openvpn route
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
 |Â
show 2 more comments
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
 |Â
show 2 more comments
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
add a comment |Â
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
add a comment |Â
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
add a comment |Â
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
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
answered Mar 15 at 0:40
user234931
25615
25615
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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