Forwarding incoming ports to another private IP on my existing setup, IPTABLES

slimcharles · 10-22-2020, 02:37 PM

Hi,
On my Debian 8 gateway:
I want to forward incoming port 9000 to 192.168.4.10:3389 and incoming 9001 port to 192.168.4.11:3389.

Code:

DHCP - WAN - eth0 -----> eth2 - LAN - 192.168.4.1

I am using rules.v4 below with iptables-restore. I don't have that much experience with iptables and all the tutorials on the web I couldn't implement this to my existing rules.

I am using Debian 8 with iptables v1.4.21

My existing iptables rules below.

Code:

# Generated by iptables-save v1.4.21 on Sat Jul 25 12:31:07 2020
*nat
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT

*filter
-A INPUT -i lo -j ACCEPT
# allow ssh, so that we do not lock ourselves
# allow ping from WAN side
--append INPUT --protocol icmp --icmp-type any --src [REDACTED_IP] --jump ACCEPT


# open ports for gateway services
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i eth2 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i bond0 -p tcp -m tcp --dport 22 -j ACCEPT

-A INPUT -i eth0 -p tcp -m tcp --dport 9091 -j ACCEPT
-A INPUT -i eth2 -p tcp -m tcp --dport 9091 -j ACCEPT

-A INPUT -i bond0 -p tcp -m tcp --dport 8200 -j ACCEPT

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

-A INPUT -i eth0 -j DROP

COMMIT

I am restoring these rules with

Code:

iptables-restore < /etc/iptables/rules.v4

Any help will be highly appreciated.Thank you.

Ser Olmy · 10-23-2020, 02:48 AM

Each forwarded port requires two rules:

A rule in the PREROUTING chain of the nat table, altering the destination IP/port (DNAT target)
A rule in the FORWARD chain of the filter table, letting the altered packet through (ACCEPT target)

You could just add the rules from the command line:

Code:

sudo iptables -t nat    -A PREROUTING -i eth0 -p tcp --dport 9000 -j DNAT --to-destination 192.168.4.10:3389
sudo iptables -t filter -A FORWARD    -d 192.168.4.10/32 -p tcp --dport 3389 -j ACCEPT
sudo iptables -t nat    -A PREROUTING -i eth0 -p tcp --dport 9001 -j DNAT --to-destination 192.168.4.11:3389
sudo iptables -t filter -A FORWARD    -d 192.168.4.11/32 -p tcp --dport 3389 -j ACCEPT

Then just save the new ruleset with iptables-save.

Note: The "-A" switch causes the rules to be added below any existing rules, which may not be appropriate in all scenarios. It depends on whether or not there are any catch-all rules in the existing ruleset.

slimcharles · 10-23-2020, 08:09 AM

Thank you for the reply. I added these rules from the terminal.

Code:

sudo iptables -t nat    -A PREROUTING -i eth0 -p tcp --dport 9000 -j DNAT --to-destination 192.168.4.10:3389
sudo iptables -t filter -A FORWARD    -d 192.168.4.10/22 -p tcp --dport 3389 -j ACCEPT
sudo iptables -t nat    -A PREROUTING -i eth0 -p tcp --dport 9001 -j DNAT --to-destination 192.168.4.11:3389
sudo iptables -t filter -A FORWARD    -d 192.168.4.11/22 -p tcp --dport 3389 -j ACCEPT

But, didn't work out.
I believe the reason is adding these new rules after

Code:

-A INPUT -i eth0 -j DROP

but I am not sure, tho.

I tried to flush iptables and try to add them but still not working.
I am using commands below for flushing.

Code:

ipt="/sbin/iptables"
## Failsafe - die if /sbin/iptables not found
[ ! -x "$ipt" ] && { echo "$0: \"${ipt}\" command not found."; exit 1; }
$ipt -P INPUT ACCEPT
$ipt -P FORWARD ACCEPT
$ipt -P OUTPUT ACCEPT
$ipt -F
$ipt -X
$ipt -t nat -F
$ipt -t nat -X
$ipt -t mangle -F
$ipt -t mangle -X
$ipt -t raw -F
$ipt -t raw -X

Can you show me how to apply all the rules above from the terminal or from the scratch?
I tried to add them to the rules.v4 so I can iptables-restore < rules.v4

Code:

# Generated by iptables-save v1.4.21 on Sat Jul 25 12:31:07 2020
*nat
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT

*filter
-A INPUT -i lo -j ACCEPT
# allow ssh, so that we do not lock ourselves
# allow ping from WAN side
--append INPUT --protocol icmp --icmp-type any --src [REDACTED_IP] --jump ACCEPT


# open ports for gateway services
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i eth2 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i bond0 -p tcp -m tcp --dport 22 -j ACCEPT

-A INPUT -i eth0 -p tcp -m tcp --dport 9091 -j ACCEPT
-A INPUT -i eth2 -p tcp -m tcp --dport 9091 -j ACCEPT

-A INPUT -i eth2 -p tcp -m tcp --dport 8200 -j ACCEPT
-A INPUT -i bond0 -p tcp -m tcp --dport 8200 -j ACCEPT

-t nat    -A PREROUTING -i eth0 -p tcp --dport 9000 -j DNAT --to-destination 192.168.4.10:3389
-t filter -A FORWARD    -d 192.168.4.10/22 -p tcp --dport 3389 -j ACCEPT
-t nat    -A PREROUTING -i eth0 -p tcp --dport 9001 -j DNAT --to-destination 192.168.4.11:3389
-t filter -A FORWARD    -d 192.168.4.11/22 -p tcp --dport 3389 -j ACCEPT

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

-A INPUT -i eth0 -j DROP

COMMIT

but then again iptables gives me this error.

Code:

iptables-restore v1.4.21: The -t option (seen in line 24) cannot be used in iptables-restore.

Ser Olmy · 10-23-2020, 11:44 AM

Quote:

Originally Posted by slimcharles

But, didn't work out.
I believe the reason is adding these new rules after

Code:

-A INPUT -i eth0 -j DROP

but I am not sure, tho.

Not likely. Packets that have been altered by a rule in the PREROUTING chain of the nat table are never processed by the INPUT chain (of the filter fable), as the destination address is no longer local. Instead, they hit the FORWARD chain.

Quote:

Originally Posted by slimcharles

I tried to flush iptables and try to add them but still not working.

How did you test the port forwarding? Note that:

A forwarded port cannot be accessed from inside the same network as the destination host, due to the asymmetric routing that will invariably take place.
By default, the firewall on a Windows host will most likely block incoming RDP connections from a non-local network.

Quote:

Originally Posted by slimcharles

I tried to add them to the rules.v4 so I can iptables-restore < rules.v4

I've added the rules in red below:

Code:

# Generated by iptables-save v1.4.21 on Sat Jul 25 12:31:07 2020
*nat
-A PREROUTING -i eth0 -p tcp -m tcp --dport 9000 -j DNAT --to-destination 192.168.4.10:3389
-A PREROUTING -i eth0 -p tcp -m tcp --dport 9001 -j DNAT --to-destination 192.168.4.11:3389
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT

*filter
-A INPUT -i lo -j ACCEPT
# allow ssh, so that we do not lock ourselves
# allow ping from WAN side
--append INPUT --protocol icmp --icmp-type any --src <ip_address> --jump ACCEPT


# open ports for gateway services
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i eth2 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i bond0 -p tcp -m tcp --dport 22 -j ACCEPT

-A INPUT -i eth0 -p tcp -m tcp --dport 9091 -j ACCEPT
-A INPUT -i eth2 -p tcp -m tcp --dport 9091 -j ACCEPT

-A INPUT -i eth2 -p tcp -m tcp --dport 8200 -j ACCEPT
-A INPUT -i bond0 -p tcp -m tcp --dport 8200 -j ACCEPT

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

-A INPUT -i eth0 -j DROP

-A FORWARD -d 192.168.4.10/22 -p tcp -m tcp --dport 3389 -j ACCEPT
-A FORWARD -d 192.168.4.11/22 -p tcp -m tcp --dport 3389 -j ACCEPT

COMMIT

slimcharles · 10-23-2020, 03:04 PM

I am outside of that network. I am scanning with nmap on another debian.
and the ports doesn't show up like 22 and 9091.

I also can't rdp to those 9000 and 9001 ports.

IPs are correct ports are correct something is not right here.
I appreciate you've done so far but couldnt make it work.

Also can you redact my actual IP?
That was my mistake.

Ser Olmy · 10-23-2020, 04:14 PM

Quote:

Originally Posted by slimcharles

I am outside of that network. I am scanning with nmap on another debian.
and the ports doesn't show up like 22 and 9091.

I also can't rdp to those 9000 and 9001 ports.

Well, 22 really ought to show up, but there could be several reasons why the RDP forwarding doesn't work.

Try this:

Run sudo tcpdump -i eth0 tcp dst port 9000 on the firewall then probe the port from an external host. If tcpdump doesn't report any incoming packets, the problem is external and there's not much you can do.
Assuming (1) worked, run sudo tcpdump -i eth2 tcp port 3389 and host 192.168.4.90 and probe port 9000 again [*]. If nothing shows up, your firewall isn't NATing/forwarding properly.
If the command in (2) produced some output, check that it contains references to packets in both directions: First a packet from the external IP address and some random TCP port to 192.168.4.90/TCP/3398, and then a reply from 192.168.4.90/TCP/3389 to whatever external IP and port you happened to be using. If the reply is missing, check the Windows firewall and gateway IP.

[*] I see you have references to three interfaces in your ruleset: eth0, eth2 and bond0. It seems obvious that eth0 must be the external interface (with a public IP address), but I'm not sure which interface is servicing the 192.168.4.0 subnet, eth2 or bond0. I went with eth2, but if that's wrong, just replace the interface name in (2) above.

You may also want to try telnet 192.168.4.90 3389 or nc 192.168.4.90 3389 from the firewall, just to make sure the service is accessible.

Quote:

Originally Posted by slimcharles

Also can you redact my vps' IP?
That was my mistake.

No problem. (Although IP addresses aren't really sensitive information; after all they're on the public Internet.)

slimcharles · 10-23-2020, 04:37 PM

Code:

eth0 --- WAN - DHCP
eth2 --- LAN - Static - 192.168.4.0/22
eth1--
     |-bond0 - Static - 192.168.7.251
eth3--

The nics are correct, Local IPs are correct.
The bash script I am using for flushing iptables is:

Code:

#!/bin/sh
echo "Stopping IPv4 firewall and allowing everyone..."
ipt="/sbin/iptables"
## Failsafe - die if /sbin/iptables not found
[ ! -x "$ipt" ] && { echo "$0: \"${ipt}\" command not found."; exit 1; }
$ipt -P INPUT ACCEPT
$ipt -P FORWARD ACCEPT
$ipt -P OUTPUT ACCEPT
$ipt -F
$ipt -X
$ipt -t nat -F
$ipt -t nat -X
$ipt -t mangle -F
$ipt -t mangle -X
$ipt -t raw -F
$ipt -t raw -X

and I do

Code:

iptables-restore < /etc/iptables/rules.v4

rules.v4:

Code:

# Generated by iptables-save v1.4.21 on Sat Jul 25 12:31:07 2020
*nat
-A PREROUTING -i eth0 -p tcp -m tcp --dport 9000 -j DNAT --to-destination 192.168.4.10:3389
-A PREROUTING -i eth0 -p tcp -m tcp --dport 9001 -j DNAT --to-destination 192.168.4.11:3389
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT

*filter
-A INPUT -i lo -j ACCEPT
# allow ssh, so that we do not lock ourselves
# allow ping from WAN side
--append INPUT --protocol icmp --icmp-type any --src <ip_address> --jump ACCEPT


# open ports for gateway services
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i eth2 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i bond0 -p tcp -m tcp --dport 22 -j ACCEPT

-A INPUT -i eth0 -p tcp -m tcp --dport 9091 -j ACCEPT
-A INPUT -i eth2 -p tcp -m tcp --dport 9091 -j ACCEPT

-A INPUT -i eth2 -p tcp -m tcp --dport 8200 -j ACCEPT
-A INPUT -i bond0 -p tcp -m tcp --dport 8200 -j ACCEPT

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

-A INPUT -i eth0 -j DROP

-A FORWARD -d 192.168.4.10/22 -p tcp -m tcp --dport 3389 -j ACCEPT
-A FORWARD -d 192.168.4.11/22 -p tcp -m tcp --dport 3389 -j ACCEPT

COMMIT

After all these, when I scan the WAN IP outside of the network, the result is:

Code:

Starting Nmap 7.40 ( https://nmap.org ) at 2020-10-24 00:32 +03
Nmap scan report for [WAN_IP]
Host is up (0.12s latency).
Not shown: 998 filtered ports
PORT     STATE SERVICE
22/tcp   open  ssh
9091/tcp open  xmltec-xmlmail

Nmap done: 1 IP address (1 host up) scanned in 11.51 seconds

Is this weird or normal?

Do I need to activate some module on kernel or anything?

Thank you for your replies.

Ser Olmy · 10-23-2020, 07:08 PM

You need to figure out how far the packets get and where they are dropped.

Use tcpdump -i eth0 to verify that the probes arrive at the relevant ports.

Use tcpdump -i eth2 to see that NATed packets are leaving the firewall and replies are coming in from the Windows hosts.

I see your WAN interface is using DHCP. Do you have a public IP on that interface, or is there another router involved (dual NAT)?

BTW, your "flush" script is potentially dangerous, as it leaves all chains empty and all policies set to ACCEPT. I'm not seeing any policies in your iptables-save ruleset, so unless you edited out those parts before posting, all packets not handled by a specific firewall rule is simply let through. That's probably not what you want.