LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)
-   -   iptables port forwarding not working (https://www.linuxquestions.org/questions/linux-networking-3/iptables-port-forwarding-not-working-4175650559/)

mfoley 03-20-2019 11:37 AM
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.

Ser Olmy 03-20-2019 08:31 PM
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".

mfoley 03-21-2019 01:45 AM
Quote:
Originally Posted by Ser Olmy (Post 5976069)
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

pingu_penguin 03-21-2019 05:04 AM
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.

Ser Olmy 03-21-2019 07:04 AM
Quote:
Originally Posted by mfoley (Post 5976114)
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.)

mfoley 03-21-2019 11:50 AM
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.

pingu_penguin 03-21-2019 01:04 PM
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.

Ser Olmy 03-21-2019 03:23 PM
Quote:
Originally Posted by pingu_penguin (Post 5976292)
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 (Post 5976292)
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.

pingu_penguin 03-21-2019 03:57 PM
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.

mfoley 03-21-2019 04:31 PM
Quote:
Originally Posted by pingu_penguin (Post 5976292)
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.

Ser Olmy 03-22-2019 10:58 AM
Quote:
Originally Posted by mfoley (Post 5976349)
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 (Post 5976349)
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 (Post 5976349)
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 (Post 5976349)
without buying some expensive syslog tool.
Eh, you do know your Linux box contains a perfectly good (and free) syslog server?

:)

mfoley 03-22-2019 02:31 PM
Quote:
Originally Posted by Ser Olmy (Post 5976547)
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!

Ser Olmy 03-22-2019 03:01 PM
Quote:
Originally Posted by mfoley (Post 5976607)
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 (Post 5976607)
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 (Post 5976607)
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 (Post 5976607)
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 (Post 5976607)
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.

mfoley 03-25-2019 11:05 AM
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.)

mfoley 03-25-2019 11:57 AM
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.

Ser Olmy 03-25-2019 07:23 PM
Quote:
Originally Posted by mfoley (Post 5977602)
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
:
Change the tcpdump command to:
Code:
tcpdump -tttt -l -i eth1 tcp port 1912 or tcp port 3389
You need to ascertain whether or not 192.168.0.2 is actually NATing and forwarding the packet, and if so, what the transmitted packet looks like.

mfoley 03-26-2019 03:21 AM
Did as you suggested:
Code:
> tcpdump -tttt -ln -i eth1 tcp port 1912 or tcp port 3389
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-26 04:17:38.242129 IP 184.57.114.221.62961 > 192.168.0.2.1912: Flags [S], seq 3350291930, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
2019-03-26 04:17:38.242153 IP 184.57.114.221.62961 > 192.168.0.58.3389: Flags [S], seq 3350291930, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
2019-03-26 04:17:41.247176 IP 184.57.114.221.62961 > 192.168.0.2.1912: Flags [S], seq 3350291930, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
2019-03-26 04:17:41.247187 IP 184.57.114.221.62961 > 192.168.0.58.3389: Flags [S], seq 3350291930, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
2019-03-26 04:17:47.246120 IP 184.57.114.221.62961 > 192.168.0.2.1912: Flags [S], seq 3350291930, win 8192, options [mss 1460,nop,nop,sackOK], length 0
2019-03-26 04:17:47.246147 IP 184.57.114.221.62961 > 192.168.0.58.3389: Flags [S], seq 3350291930, win 8192, options [mss 1460,nop,nop,sackOK], length 0
At that point, connection fails on the remote. It appears that the remote (184.57.114.221) is being routed to port 3389 on the Windows computer (2nd output line, above), but still no connection. I've turned off the firewall on the Windows computer.

Ser Olmy 03-26-2019 05:52 AM
Quote:
Originally Posted by mfoley (Post 5977864)
Did as you suggested:
Code:
> tcpdump -tttt -ln -i eth1 tcp port 1912 or tcp port 3389
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-26 04:17:38.242129 IP 184.57.114.221.62961 > 192.168.0.2.1912: Flags [S], seq 3350291930, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
2019-03-26 04:17:38.242153 IP 184.57.114.221.62961 > 192.168.0.58.3389: Flags [S], seq 3350291930, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
As you can see, the outgoing packet to 192.168.0.58:3389 still has the original source address (187.57.114.221). That means the Windows computer won't be routing its relpies through 192.168.0.2, but rather use the default gateway (the SonicWall) which, since it's not expecting replies from 192.168.0.58, will just drop the packets.

The POSTROUTING rule isn't catching packets from external hosts going to the Windows system, since it was only designed to handle the 2nd hairpin scenario (local PCs connecting to the Windows host via 192.168.0.2). Try adding this rule:
Code:
iptables -t nat -A POSTROUTING -o eth1 -d 192.168.0.58 -p tcp --dport 3389 -j SNAT --to-source 192.168.0.2
tcpdump should then show packets exiting eth1 with a source address of 192.168.0.2. The connection from the external host might even work. :)

mfoley 03-26-2019 09:31 PM
Holy Firewall, Batman! That worked! You're a genius! I'll have to study this some more and incorporate it with my existing firewall, and route the other workstations in the same way.

To recap for the benefit of others: I want to do this because the new Sonicwall firewall/router/gateway apparently does not alert or counter-measure on brute-force attempts on RDP and VNC ports. I'm not certain they do so for their VPN either. I'm discussing this on the Sonicall forum. My 192.168.0.2 server has a counter-measure script to detect and block such attacks. Hence this thread.

As a stripped-down iptables script, I've ended up with the following:
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 INPUT ACCEPT
iptables -P FORWARD ACCEPT
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:3389

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

# Catch packets from external hosts going to the Windows system
iptables -t nat -A POSTROUTING -o eth1 -d 192.168.0.58 -p tcp --dport 3389 -j SNAT --to-source 192.168.0.2

mfoley 03-27-2019 12:10 PM
Possibly last question. I've configured several of the workstations, Windows, Linux and Mac. All work! This entails 4 iptables lines per workstation:
Code:
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
iptables -t nat -A POSTROUTING -o eth1 -d 192.168.0.58 -p tcp --dport 3389 -j SNAT --to-source 192.168.0.2
No big deal, but can I consolidate some of these lines? For example, could I:
Code:
iptables -A FORWARD -i eth1 -d 192.168.0.4 -p tcp --dport 3389 -j ACCEPT
iptables -A FORWARD -i eth1 --dst-range 192.168.0.50-192.168.0.53 -p tcp --dport 3389 -j ACCEPT
iptables -A FORWARD -i eth1 --dst-range 192.168.0.55-192.168.0.60 -p tcp --dport 3389 -j ACCEPT
iptables -A FORWARD -i eth1 --dst-range 192.168.0.61-192.168.0.63 -p tcp --dport 5900 -j ACCEPT

# and likewise:
iptables -t nat -A POSTROUTING -o eth1 --dst-range 192.168.0.50-192.168.0.53 -p tcp --dport 3389 -j SNAT --to-source 192.168.0.2
:
Not sure about trying this "live" as I am remote. Feedback appreciated.

Unfortunately, my 5900 redirects and 3389 redirects are interspersed, so I don't have clean ip ranges, but that's a task for another day.


All times are GMT -5. The time now is 03:33 PM.