LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
  Search this Thread
Old 03-20-2019, 11:37 AM   #1
mfoley
Senior Member
 
Registered: Oct 2008
Location: Columbus, Ohio USA
Distribution: Slackware
Posts: 1,591

Rep: Reputation: 128Reputation: 128
iptables port forwarding not working


I'm having a difficult time this week with networking! I have the following port forward set up on host 192.168.0.2 with iptables:
Code:
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 1912 -j DNAT --to-destination 192.168.0.58:3389
Host 192.168.0.58 is a Windows computer. 192.168.0.2 is a server that acts as a router with iptables settings as shown. I want to forward requests to 192.168.0.2:1912 to 192.168.0.58:3389. Logged in as root on 192.168.0.2 I get:
Code:
> telnet localhost 1912
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused

> telnet 192.168.0.2 1912
Trying 192.168.0.2...
telnet: connect to address 192.168.0.2: Connection refused

> telnet 192.168.0.58 3389
Trying 192.168.0.58...
Connected to 192.168.0.58.
Escape character is '^]'.
So, why is my telnet to 1912 not connecting to 3389 on host .58? Both computers are on the same subnet and eth1 is correct.

Last edited by mfoley; 03-20-2019 at 11:38 AM.
 
Old 03-20-2019, 08:31 PM   #2
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 2,536

Rep: Reputation: Disabled
When you telnet to localhost, no routing is involved. Hence, the packet isn't passing through the PREROUTING chain of the nat table.

Also, even if the forwarding had worked, what do you think the source IP of a packet destined for localhost might be? So even if the NAT setup worked and the kernel on the router was willing to forward the NATed packet to the other host, all you'd get would be complaints in the kernel log on the receiving side about "martians".
 
Old 03-21-2019, 01:45 AM   #3
mfoley
Senior Member
 
Registered: Oct 2008
Location: Columbus, Ohio USA
Distribution: Slackware
Posts: 1,591

Original Poster
Rep: Reputation: 128Reputation: 128
Quote:
Originally Posted by Ser Olmy View Post
When you telnet to localhost, no routing is involved. Hence, the packet isn't passing through the PREROUTING chain of the nat table.
Given that, I tried from a different host (192.168.0.3):
Code:
$ telnet 192.168.0.2 1912
Trying 192.168.0.2...
^C
Still no connection. I also added:
Code:
iptables --append FORWARD --in-interface eth1 -j ACCEPT
But that didn't help.

Since I'm not using localhost, what could still be the problem?
Code:
> iptables -v -L -n -t nat
Chain PREROUTING (policy ACCEPT 74141 packets, 6573K bytes)
 pkts bytes target     prot opt in     out     source               destination         
    1    60 DNAT       tcp  --  eth1   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:1912 to:192.168.0.58:3389

Chain INPUT (policy ACCEPT 64665 packets, 5366K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 38107 packets, 2782K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 38792 packets, 2819K bytes)
 pkts bytes target     prot opt in     out     source               destination
 
Old 03-21-2019, 05:04 AM   #4
pingu_penguin
Member
 
Registered: Aug 2004
Distribution: mostly ubuntu , but want to migrate strongly to slack.
Posts: 256

Rep: Reputation: 56
Your port forwarding rule seems correct.

Try connecting from a host that is outside your network.

The whole concept of port forwarding is to let an external host access a service/port on a host on your internal network.

I personally doubt if it works like this.
 
Old 03-21-2019, 07:04 AM   #5
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 2,536

Rep: Reputation: Disabled
Quote:
Originally Posted by mfoley View Post
Given that, I tried from a different host (192.168.0.3):
Code:
$ telnet 192.168.0.2 1912
Trying 192.168.0.2...
^C
Still no connection. I also added:
Code:
iptables --append FORWARD --in-interface eth1 -j ACCEPT
But that didn't help.

Since I'm not using localhost, what could still be the problem?
As pingu_penguin alluded to, when you try to connect from a host in the same network as the NATed destination host, the return path becomes an issue.

The NATed packet arriving at 192.168.0.58 will have 192.168.0.3 as its source address, so naturally 192.168.0.58 will reply directly to 192.168.0.3 rather than sending the packet through 192.168.0.2 (the router).

However, 192.168.0.3 sent a packet to 192.168.0.2, and isn't expecting a reply from 192.168.0.58. The reply packet is thus discarded, and the TCP stack on 192.168.0.3 will keep retrying a few times until the timeout threshold is reached.

Port forwarding (destination NAT) requires two iptables rules: one rule in the PREROUTING chain of the nat table to alter the destination address (and possibly the port number) of the packet, and one rule in the FORWARD chain of the filter table to allow the altered packet to pass through the router. You have both of these in place.

Additionally, you will need a rule in the POSTROUTING chain of the nat table if you want your setup to handle connections originating from same IP network as the destination host (often referred to as "hairpin nat" or "loopback nat"). In your case, the rule would look something like this:
Code:
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d 192.168.0.58 -p tcp --dport 1912 -j SNAT --to-source 192.168.0.2
This will make NATed packets appear to originate from the router itself, ensuring the return path will be correct.

Technically, you could use the external IP address of the router as the "--to-source" address, or really any IP address outside the 192.168.0.0/24 network, but it's common practice to just use the local router IP. Also, you could leave out the "-p tcp --dport 1912" part of the rule if you want to handle multiple forwarded ports with a single rule.

(And of course there will have to be a rule in the FORWARD chain of the filter table to handle return packets in general, typically one matching the ESTABLISHED and RELATED states, but that's true for any firewall/router setup and is not specific to port forwarding scenarios.)
 
Old 03-21-2019, 11:50 AM   #6
mfoley
Senior Member
 
Registered: Oct 2008
Location: Columbus, Ohio USA
Distribution: Slackware
Posts: 1,591

Original Poster
Rep: Reputation: 128Reputation: 128
I had this port forwarding thing working very well before installing a Sonicwall firewall as the new gateway and router. Before that, 192.168.0.2 was the gateway/router with two network cards: eth0 - Internet facing; eth1 LAN. The rules which worked before were:
Code:
iptables -t nat -P POSTROUTING ACCEPT
iptables -t mangle -P POSTROUTING ACCEPT
iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE
iptables --append FORWARD --in-interface eth1 -j ACCEPT
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 1912 -j DNAT --to-destination 192.168.0.58:3389
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
After putting in the Sonicwall, I set up the various port-forwards there. However, the Sonicwall apparently does not alert or block accesses on non-standard ports (e.g. 1912), so hackers can try to brute force these ports all day long -- which they have been: over 38,000 attempts in the past 20 days and going strong. I have countermeasure scripts on 192.168.0.2, so I want to direct these ports back to that host so it can look for the attempts and block the IPs.

I have managed to get the Sonicwall to forward this 1912 port to 192.168.0.2. If I do 'nc -v -l -p 1912' on this host and telnet to it from the outside, I get a connect message. That part works. However, I'm not still able to fix up the firewall script on this host to get forwarding to .58.

I was only trying to connect from within the LAN to eliminate the Sonicwall as the problem. But since I can connect to 1912 from the outside, I don't have to try messing with intra-LAN connections. I've modified my rules per Ser Olmy's advice (I think) as follows:
Code:
iptables -t nat -P POSTROUTING ACCEPT
iptables -t mangle -P POSTROUTING ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d 192.168.0.58 -p tcp --dport 1912 -j SNAT --to-source 192.168.0.2
iptables --append FORWARD --in-interface eth1 -j ACCEPT
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 1912 -j DNAT --to-destination 192.168.0.58:3389
However, I still get a "Connection refused" (after a minute) when trying to connect from the outside.

Last edited by mfoley; 03-21-2019 at 11:54 AM.
 
Old 03-21-2019, 01:04 PM   #7
pingu_penguin
Member
 
Registered: Aug 2004
Distribution: mostly ubuntu , but want to migrate strongly to slack.
Posts: 256

Rep: Reputation: 56
IMHO this line is wrong :

Quote:
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d 192.168.0.58 -p tcp --dport 1912 -j SNAT --to-source 192.168.0.2
The above line doesn't port forward unless I'm horribly mistaken.

SNAT is used to masquerade if you have a static IP.
In the first example it worked correctly. SNAT and -j MASQUERADE are two methods of sharing the internet connection, coupled with ip forwarding.

Give the following a try and let me know :

# echo 1 > /proc/sys/net/ipv4/ip_forward ( avoid iptables FORWARD chain temporarily)
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE (where eth0 is your public interface)
# iptables -t nat -A PREROUTING -p tcp -i eth0 -s 0/0 --dport 1912 -j DNAT --to-destination 192.168.0.58:3389 (enables PF)

additionally you could try and substitute -d <your internet ip> with -i eth0 -s 0/0

This is all assuming your 192.168.0.2 is the router machine.

Hope this helps.
 
Old 03-21-2019, 03:23 PM   #8
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 2,536

Rep: Reputation: Disabled
Quote:
Originally Posted by pingu_penguin View Post
The above line doesn't port forward unless I'm horribly mistaken.
You're not; what it does is hide outgoing routed traffic of a particular kind behind 192.168.0.2. The purpose is to handle a hairpin NAT scenario where the return path would otherwise point directly to the originating host, bypassing the NAT router altogether.

Quote:
Originally Posted by pingu_penguin View Post
SNAT is used to masquerade if you have a static IP.
Not quite. "SNAT" means "Source Network Address Translation", that is, change the source IP address of a packet.

You can of course use it instead of the MASQUERADE target if the IP address of the outgoing interface never changes.
 
Old 03-21-2019, 03:57 PM   #9
pingu_penguin
Member
 
Registered: Aug 2004
Distribution: mostly ubuntu , but want to migrate strongly to slack.
Posts: 256

Rep: Reputation: 56
Quote:
what it does is hide outgoing routed traffic of a particular kind behind 192.168.0.2. The purpose is to handle a hairpin NAT scenario where the return path would otherwise point directly to the originating host, bypassing the NAT router altogether.
interesting. never thought about that.
 
Old 03-21-2019, 04:31 PM   #10
mfoley
Senior Member
 
Registered: Oct 2008
Location: Columbus, Ohio USA
Distribution: Slackware
Posts: 1,591

Original Poster
Rep: Reputation: 128Reputation: 128
Quote:
Originally Posted by pingu_penguin View Post
IMHO this line is wrong :
Give the following a try and let me know :

# echo 1 > /proc/sys/net/ipv4/ip_forward ( avoid iptables FORWARD chain temporarily)
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE (where eth0 is your public interface)
# iptables -t nat -A PREROUTING -p tcp -i eth0 -s 0/0 --dport 1912 -j DNAT --to-destination 192.168.0.58:3389 (enables PF)
So, given the commentary between pingu_penguin and Ser Olmy, is pingu_penguin's suggestion above still worth a try? In any case, it probably needs some modifications ...

I thought a few things were obvious (only because I've had my face in it for so long), but need clarification:

Since adding the Sonicwall (192.168.0.1), host 192.168.0.2 is no longer the gateway or router. eth0 was the Internet facing interface, but is now no longer used at all. eth1 is on the same 192.168.0.0/24 subnet as the Sonicwall (192.168.0.1), which is now the gateway. There is no eth0 any more.

Currently, all routing has been removed from 192.168.0.2 to the Sonicwall, but I want to forward certain ports from the Sonicwall to 192.168.0.2 (which does work) in order to let that host route them to other LAN hosts and, importantly, to capture the attempted break-in logs.

So, given NO eth0, how should the following be fixed (on 192.168.0.2). It does not currently work:
Code:
iptables -t nat -P POSTROUTING ACCEPT
iptables -t mangle -P POSTROUTING ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d 192.168.0.58 -p tcp --dport 1912 -j SNAT --to-source 192.168.0.2
iptables --append FORWARD --in-interface eth1 -j ACCEPT
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 1912 -j DNAT --to-destination 192.168.0.58:3389
BTW - I am finding the Sonicwall device virtually impossible to configure to get any useful log data out of without buying some expensive syslog tool. So, I'd really like to just get these ports back to my 192.168.0.2 host and let it take care of countermeasures like it used to. This all used to work just fine before the Sonicwall, so it shouldn't be too difficult to come up with the correct iptables config.

Last edited by mfoley; 03-22-2019 at 07:31 AM.
 
Old 03-22-2019, 10:58 AM   #11
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 2,536

Rep: Reputation: Disabled
Quote:
Originally Posted by mfoley View Post
Currently, all routing has been removed from 192.168.0.2 to the Sonicwall, but I want to forward certain ports from the Sonicwall to 192.168.0.2 (which does work) in order to let that host route them to other LAN hosts and, importantly, to capture the attempted break-in logs.
Since 192.168.0.2 is not the gateway for the 192.168.0.0/24 network, you run into the "hairpin NAT" issue. You will have to
  • either alter the setup to make 192.168.0.2 the gateway, or
  • perform SNAT on all port forwarded packets that leave 192.168.0.2
Choose whichever solution suits your setup best.
Quote:
Originally Posted by mfoley View Post
So, given NO eth0, how should the following be fixed (on 192.168.0.2). It does not currently work:
Code:
iptables -t nat -P POSTROUTING ACCEPT
iptables -t mangle -P POSTROUTING ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d 192.168.0.58 -p tcp --dport 1912 -j SNAT --to-source 192.168.0.2
iptables --append FORWARD --in-interface eth1 -j ACCEPT
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 1912 -j DNAT --to-destination 192.168.0.58:3389
This ought to do the trick (see the inline comments):
Code:
# Flush existing ruleset:
iptables -F
iptables -t nat -F
# Set reasonable policy defaults (that is,
# these are "reasonable" for an exposed
# firewall; you may decide that an input
# policy of ACCEPT is, well, acceptable in
# this particular scenario):
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# You really don't want to stop loopback
# traffic with a DROP policy:
iptables -A INPUT -i lo -j ACCEPT
# Allow existing sessions for both local and
# routed traffic:
iptables -A INPUT   -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
# If the INPUT policy is indeed DROP, add
# rules for relevant local services here;
# the example below handles SSH:
iptables -A INPUT -p tcp --dport 22 -m state --STATE NEW -j ACCEPT
# Forward TCP port 1912 to 192.168.0.58:3398
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 1912 -j DNAT --to-destination 192.168.0.58:3389
# Allow the forwarded packet through;
# remember to reference the translated IP
# address and portnumber, not the NATed
# ones:
iptables -A FORWARD -i eth1 -d 192.168.0.58 -p tcp --dport 3389 -j ACCEPT
# Preserve return path by NATing behind
# 192.168.0.2 (eth1):
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d 192.168.0.58 -p tcp --dport 3389 -j SNAT --to-source 192.168.0.2
Add services and ports as required. As mentioned, you could add a general hairpin NAT rule to handle any and all ports you forward from the SonicWall by replacing "-d 192.168.0.58 -p tcp --dport 3389" with just "-d 192.168.0.0/24" in the last rule above.
Quote:
Originally Posted by mfoley View Post
BTW - I am finding the Sonicwall device virtually impossible to configure to get any useful log data out of
Agreed. The same goes for most routers on the market, unfortunately.
Quote:
Originally Posted by mfoley View Post
without buying some expensive syslog tool.
Eh, you do know your Linux box contains a perfectly good (and free) syslog server?

 
Old 03-22-2019, 02:31 PM   #12
mfoley
Senior Member
 
Registered: Oct 2008
Location: Columbus, Ohio USA
Distribution: Slackware
Posts: 1,591

Original Poster
Rep: Reputation: 128Reputation: 128
Quote:
Originally Posted by Ser Olmy View Post
Since 192.168.0.2 is not the gateway for the 192.168.0.0/24 network, you run into the "hairpin NAT" issue. You will have to
  • either alter the setup to make 192.168.0.2 the gateway, or
  • perform SNAT on all port forwarded packets that leave 192.168.0.2
Choose whichever solution suits your setup best.
I cannot make 192.168.0.2 the gateway. That has to be the Sonicwall for a variety of reasons which I discovered the hard way.

I created a firewall script of exactly your example, except to be as liberal as possible I did not default INPUT and FORWARD to DROP. I made them ACCEPT. Otherwise, I basically copy/pasted your example. Still no joy. With the following running on 192.168.0.2:
Code:
tcpdump -tttt -l -nn portrange 1901-1914 and 'tcp[13] & 4 != 0'
There is NOTHING logged when I try to connect remotely to 1912 with your example iptables script. If I reset the iptables to have no NAT entries, then and then try to connect remotely, I get:
Code:
2019-03-22 15:21:19.337430 IP 192.168.0.2.1912 > 184.57.114.221.34966: Flags [R.], seq 0, ack 4106531947, win 0, length 0
So, with the NAT routing tcpdump doesn't even see the packet. Without NAT routing, it does. Why? (and sorry for this labyrinth. I thought forwarding a port to another host would be a relatively simple thing!)
Quote:
Eh, you do know your Linux box contains a perfectly good (and free) syslog server?
I know there is syslogd, but having never used Sonicwall before I've not been sure if their meaning is the same as Linux's meaning. In any case, I'm having as much problem getting the Sonicwall to send syslog message to 192.168.0.2. I've posted a thread on that to the Sonicwall forum. I'd like SOMETHING to work!

Last edited by mfoley; 03-22-2019 at 02:34 PM.
 
Old 03-22-2019, 03:01 PM   #13
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 2,536

Rep: Reputation: Disabled
Quote:
Originally Posted by mfoley View Post
I cannot make 192.168.0.2 the gateway. That has to be the Sonicwall for a variety of reasons which I discovered the hard way.
How about having a separate IP network between eth0 on the Linux host and the SonicWall, and use dual NAT? After all, that's what you're attempting to implement anyway.

Quote:
Originally Posted by mfoley View Post
I created a firewall script of exactly your example, except to be as liberal as possible I did not default INPUT and FORWARD to DROP. I made them ACCEPT.
In other words, there's nothing blocking incoming or forwarded traffic in any way.
Quote:
Originally Posted by mfoley View Post
Otherwise, I basically copy/pasted your example. Still no joy. With the following running on 192.168.0.2:
Code:
tcpdump -tttt -l -nn portrange 1901-1914 and 'tcp[13] & 4 != 0'
I'm a bit rusty when it comes to the TCP flag order, but isn't TCP flag 2 (with a value of 4) the RST flag? I believe SYN is 2, if that's what you're looking for.

But why filter on flags at all? Surely there's not that much incoming traffic on port 1912?
Quote:
Originally Posted by mfoley View Post
There is NOTHING logged when I try to connect remotely to 1912 with your example iptables script. If I reset the iptables to have no NAT entries, then and then try to connect remotely, I get:
Code:
2019-03-22 15:21:19.337430 IP 192.168.0.2.1912 > 184.57.114.221.34966: Flags [R.], seq 0, ack 4106531947, win 0, length 0
The fact that you're only seeing a reply packet should be a big hint. With the iptables ruleset enabled, you see nothing, but without it you get a TCP reset. Makes perfect sense, assuming no service is listening on port 1912 on the Linux host. With the NAT rules in place, the Windows box will either reply with a SYN/ACK or with nothing at all, depending on the Windows Firewall settings. Either way, your capture filter will catch nothing.

Try again, but look for the SYN flag (value 2) instead. Also, run these tests:
  • Can you connect to port 3389 on the Windows box from the linux host (telnet 192.168.0.58 3389 should do nicely)? If not, the Windows firewall is blocking you.
  • Does tcpdump -i eth1 host 192.168.0.58 and tcp port 3389 show outgoing packets to 192.168.0.58 when you try connecting to 192.168.0.2:1912 from another host? If not, there's a routing issue or a typo in one of the firewall rules.
  • And most important of all: When you're testing the setup by connecting to the external IP of the SonicWall, are you doing so from outside your network? Otherwise, don't expect things to work.
Quote:
Originally Posted by mfoley View Post
I thought forwarding a port to another host would be a relatively simple thing!)
It is, but you're doing slightly more than that. It's still not that hard, though; just remember to test one part of the setup at a time.
 
Old 03-25-2019, 11:05 AM   #14
mfoley
Senior Member
 
Registered: Oct 2008
Location: Columbus, Ohio USA
Distribution: Slackware
Posts: 1,591

Original Poster
Rep: Reputation: 128Reputation: 128
Thanks for your patience!

You're right, I don't really need to mask the tcpdump packet. Here's what I've done to simply things:

First, I tried with no firewall whatsoever running on 192.168.0.2. On that host I run 'nc -v -l -p 1912'. From a computer OUTSIDE this LAN, located many miles away, I run:

telnet thathost.org 1912

On the target host I get, "connect to [192.168.0.2] from cpe-184-57-114-221.columbus.res.rr.com [184.57.114.221] 45540"

So, I can definitely get to port 1912 on 192.168.0.2 from the outside. The Sonicwall is properly routing port 1912 to 192.168.0.2.

From 192.168.0.2, if I run 'telnet 192.168.0.58 3389' (the Windows computer) I get:
Code:
> telnet 192.168.0.58 3389
Trying 192.168.0.58...
Connected to 192.168.0.58.
Escape character is '^]'.
Therefore, host 192.168.0.2 can reach the Windows machine, no Windows firewall blocking. Furthermore, if I set a Linux host (192.168.0.3) to listen on that port 'nc -v -l -p 3389', I get:
Code:
> telnet 192.168.0.3 3389
Trying 192.168.0.3...
Connected to 192.168.0.3.
Escape character is '^]'.
and on 192.168.0.3 I get "connect to [192.168.0.3] from mail.hprs.local [192.168.0.2] 33318". I don't know if this last test matters, but maybe in case I want to bypass the Windows box and just use Linux for experimentation.

Next, I run the firewall commands per your previous suggestion, which are, if I understood correctly:
Code:
iptables -F
iptables -t nat -F
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT   -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 1912 -j DNAT --to-destination 192.168.0.58:3389
iptables -A FORWARD -i eth1 -d 192.168.0.58 -p tcp --dport 3389 -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d 192.168.0.58 -p tcp --dport 3389 -j SNAT --to-source 192.168.0.2
This gives:
Code:
> iptables -L -v -n
Chain INPUT (policy ACCEPT 22 packets, 6071 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
   62  7857 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    0     0 ACCEPT     tcp  --  eth1   *       0.0.0.0/0            192.168.0.58         tcp dpt:3389

Chain OUTPUT (policy ACCEPT 55 packets, 9145 bytes)
 pkts bytes target     prot opt in     out     source               destination         

> iptables -L -v -n -t nat
Chain PREROUTING (policy ACCEPT 24 packets, 1921 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DNAT       tcp  --  eth1   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:1912 to:192.168.0.58:3389

Chain INPUT (policy ACCEPT 22 packets, 1591 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 8 packets, 547 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 8 packets, 547 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 SNAT       tcp  --  *      *       192.168.0.0/24       192.168.0.58         tcp dpt:3389 to:192.168.0.2
Then I run tcpdump for port 1912 on the 192.168.0.2 host and attempt to telnet from the outside computer. On 192.168.0.2 I get:
Code:
> tcpdump -tttt -l port 1912
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
2019-03-25 11:57:20.683569 IP cpe-184-57-114-221.columbus.res.rr.com.45850 > mail.hprs.local.1912: Flags [S], seq 258769081, win 29200, options [mss 1460,sackOK,TS val 2524738611 ecr 0,nop,wscale 7], length 0
:
repeated
:
And on the remote computer I get:
Code:
$ telnet thathost.org 1912
Trying 98.102.63.107...
telnet: connect to address 98.102.63.107: Connection refused
If instead I route 1912 to Linux 192.168.0.3, and run 'nc -v -l -p 3389' on that host, same thing.

So, 192.168.0.2 is seeing the request, but it's apparently NOT routing to the Windows (or Linux) computer.

Finally, using your suggested tcpdump for the Windows host, I get:
Code:
> tcpdump -v -i eth1 host 192.168.0.58 and tcp port 3389
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
12:11:55.740293 IP (tos 0x0, ttl 57, id 21916, offset 0, flags [DF], proto TCP (6), length 60)
    cpe-184-57-114-221.columbus.res.rr.com.46266 > COMMON.hprs.local.rdp: Flags [S], cksum 0x0387 (correct), seq 687380104, win 29200, options [mss 1460,sackOK,TS val 2525613677 ecr 0,nop,wscale 7], length 0
12:11:56.743249 IP (tos 0x0, ttl 57, id 21917, offset 0, flags [DF], proto TCP (6), length 60)
    cpe-184-57-114-221.columbus.res.rr.com.46266 > COMMON.hprs.local.rdp: Flags [S], cksum 0xff9b (correct), seq 687380104, win 29200, options [mss 1460,sackOK,TS val 2525614680 ecr 0,nop,wscale 7], length 0
:
repeated
:
And again, "Connection refused" on the remote computer. Does this mean something is getting to the Windows computer? If the Windows host is seeing IP 184.57.114.221, which is not local, perhaps the firewall on Windows is kicking in!? I'll experiment a bit with that.

(btw - for various configuration reasons, as recommended by security consultants, I do not want to enable eth0 on 192.168.0.2 directly to the Sonicwall. I want to get this working with eth1, if possible.)

Last edited by mfoley; 03-25-2019 at 11:20 AM.
 
Old 03-25-2019, 11:57 AM   #15
mfoley
Senior Member
 
Registered: Oct 2008
Location: Columbus, Ohio USA
Distribution: Slackware
Posts: 1,591

Original Poster
Rep: Reputation: 128Reputation: 128
Later - tried disabling the firewall (Norton) on Windows 192.168.0.58. No difference in results. Also tried redirecting port 1914 to 3389 on Linux 192.168.0.3 where there is no firewall. Nothing on that host either.
 
  


Reply

Tags
iptables, port forwarding


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] IPtables : ssh port forwarding one port to another port issue routers Linux - Networking 7 08-07-2018 08:41 AM
[SOLVED] iptables port forward not working for port range mapping to anohter Port range in Linux 2.6.39 kinghong66 Linux - Networking 2 06-17-2015 07:17 PM
Shorewall: port forwarding problem, port is closed even after forwarding Synt4x_3rr0r Linux - Networking 2 12-13-2009 04:36 PM
IPCHAINS port forwarding and IPTABLES port forwarding ediestajr Linux - Networking 26 01-14-2007 07:35 PM
Port forwarding with iptables is not working?!! philipina Linux - Networking 1 04-03-2004 03:18 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 03:19 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration