1

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.

  • 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 '18 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 '18 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 '18 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 '18 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 '18 at 23:55
0

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.