0

I have a Windows machine and a Linux machine. Since I'm not very familiar with Windows firewalling (and not sure the OS's application level firewalling security), I wanted to open the app port to the internet from the Linux machine but not from Windows. So, it's like: The internet -> Linux:7000 -> iptables (rules to block and forward) -> Windows:7000 over ssh .

I googled and read some stackexchange posts (like this or this), tried following commands that should have worked I thought. But didn't work.

# linux machine: 192.168.0.168:7000
# windows machine: 192.168.0.111:7000
# the linux's network interface is wlp2s0, and windows's is eth0 

# ssh-ing, from the windows machine 
ssh -L 7000:localhost:7000  user@192.168.0.168

# iptables 
sudo iptables -t nat -I PREROUTING -p tcp -i wlp2s0 --dport 7000 -j DNAT --to-destination 192.168.0.111:7000
sudo iptables -A FORWARD -i wlp2s0 -o eth0 -p tcp -d 192.168.0.111 --dport 7000 -j ACCEPT

# curl to test 
curl -I 220.xx.xx.xx:7000 # this should return curl: (52) Empty reply from server for succeed, but curl: (7) Failed to connect # the global ip is connected to the linux machine

So, what's wrong with the commands?

2 Answers 2

1

I solved the problem with the following.

# on the windows
$ ssh -R 7000:localhost:7000 user@[[linuxip]] # on windowspc

# on the linux
sudo iptables -t nat -A PREROUTING -p tcp -i wlp2s0 --dport 7000 -j DNAT --to-destination [[windowsip]]:7000
sudo iptables -t nat -A POSTROUTING -j MASQUERADE

The above just does work for bypassing the connection. So the below is an example when you want to allow specific IP(s).

sudo iptables -t nat -A PREROUTING -p tcp -i wlp2s0 --dport 7000 -j DNAT --to-destination [[windowsip]]:7000
sudo iptables -t nat -A POSTROUTING -j MASQUERADE

# filter
sudo iptables -I FORWARD -i wlp2s0 -p tcp -d [[windowsip]] --dport 7000 -j DROP
sudo iptables -I FORWARD -i wlp2s0 -p tcp -d [[windowsip]] --dport 7000 -s [[allowThisIp(s)]] -j ACCEPT

Configuring iptables to port forward ssh connection to a server - Unix & Linux Stack Exchange

(I'm not completely convinced this is a best way or not (mostly for security, for system stability). If you know a better or proper way please be open to share the idea.)

0

Not necessarily an answer as such, as you've already sorted it yourself, but hopefully some comments to explain the behaviour that you were seeing might be helpful.

SHH Reverse Tunnel

In the configuration that you have, the SSH reverse tunnel is a red herring, and effectively irrelevant, because the destination IP address gets altered before it can reach the listening ssh process.

You would normally use an SSH reverse tunnel in different situations than this, usually to work around firewalls or address translation.

IPtables config

The initial config you had would alter inbound packets in the following way:

Packet Source IP Source Port Destination IP Destination Port
Original Packet <external_ip_X> <port_Y> <linux_ip> 7000
Translated Packet <external_ip_X> <port_Y> <windows_ip> 7000

The issue is that return packets would then look like:

Packet Source IP Source Port Destination IP Destination Port
Return Packet <windows_ip> 7000 <external_ip_X> <port_Y>

These return packets would go straight to the default gateway, (bypassing the linux box if it isn't set as the default gateway), which would either drop or alter the packet as it would not match an existing connection.

With the altered iptables rules, you get this instead:

Packet Source IP Source Port Destination IP Destination Port
Original Packet <external_ip_X> <port_Y> <linux_ip> 7000
Translated Packet <linux_ip> <port_Z> <windows_ip> 7000

Then the return packets would pass back through the linux box and the translation would be performed correctly in the reverse direction:

Packet Source IP Source Port Destination IP Destination Port
Original Return Packet <windows_ip> 7000 <linux_ip> <port_Z>
Translated Return Packet <linux_ip> 7000 <external_ip_X> <port_Y>

Security

A bit difficult to comment on this without knowing more about what the service on port 7000 is, but given what you have here so far, I suspect it may be simpler and clearer to just implement the same thing on the perimeter firewall/router device, depending on the capabilities of that device.

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.