Port forwarding is not opening ports

Carlos_Estrada · October 1, 2016, 11:07pm

Hi to all.

I’m trying to configure nethserver 7.2 and I need port forwarding to use with internal web server.

I configured the red and green interface. I can reach the server form the outside on port 980 (httpd-admin). I can surf the internet and every seems normal.

But when I try to configure port forwarding the server just won’t open the port. I need to know of there is something more I need to do besides creating the configuration in Gateway > Port Forwarding.

The documentation looks very easy and clear, but is not working.

Thank you.

giacomo · October 3, 2016, 7:01am

You don’t need any extra work.

Is there any errors on logs?
You should check at least:

/var/log/messages
/var/log/firewall.log

Also, post the output of the following commands:

shorewall check
grep -i DNAT /etc/shorewall/rules

alefattorini · October 3, 2016, 10:19am

Which ports? I suggest checking the machine behind NethServer, are you sure that the traffic isn’t blocked there?
tcpdump -i lan_interface port 80
on NethServer might help

Carlos_Estrada · October 3, 2016, 7:07pm

Thank you for your answer.

It turns out the problem was only with an alias IP address, not with the main IP address.

It seems Port Forwarding don’t work with an alias IP. Right?

After hours of testing I found I needed to create a VLAN for my extra IP an not an alias. Now it works ok.

I’m migrating form ClearOS and things work a little different.

Thank you.

filippo_carletti · October 3, 2016, 7:25pm

No, I have it working correctly.
You can select to forward port on any ip or through an alias.

Carlos_Estrada · October 11, 2016, 11:38pm

It is working now. I deleted the VLAN and created an alias instead and port forwarding is working fine.

I can’t tell why it wasn’t working before and how it got fixed, but thank you anyway.

Carlos_Estrada · October 21, 2016, 3:03pm

Sorry, but I realize the problem persists with VLAN or alias. It’s working for a week or 3 days and then just doesn’t work, without touching the server.

I have 3 public static IP.

2 of them are configured in nethserver. em1 and em1:0. The problem is with the alias, em1:0. It doesn’t matter which IP I use in em1 or em1:0. The problem is the same and only with the alias.

The other IP is used for wifi in a separated router and network. It is supposed to have the same access to the nethserver as the whole internet.

But the weird part here is that the problem doesn’t occur form this network. If I’m using my laptop connected to the wifi I can access the web server which is inside the nethserver network and is using port forwarding.

I even stopped snortd to see if this has something to do with it:

[root@gate ~]# systemctl status snortd
● snortd.service - SYSV: snort is a lightweight network intrusion detection tool that currently detects more than 1100 host and network vulnerabilities, portscans, backdoors, and more.
   Loaded: loaded (/etc/rc.d/init.d/snortd)
   Active: inactive (dead)
     Docs: man:systemd-sysv-generator(8)

I didi the shorewall check and it looks ok:

[root@gate ~]# shorewall check
Checking using Shorewall 5.0.8.2...
Processing /etc/shorewall/params ...
Processing /etc/shorewall/shorewall.conf...
Loading Modules...
Checking /etc/shorewall/zones...
Checking /etc/shorewall/interfaces...
Determining Hosts in Zones...
Locating Action Files...
Checking /etc/shorewall/policy...
Running /etc/shorewall/initdone...
Adding Anti-smurf Rules
Adding rules for DHCP
Checking TCP Flags filtering...
Checking Kernel Route Filtering...
Checking Martian Logging...
Checking /etc/shorewall/tcinterfaces...
Checking /etc/shorewall/tcpri...
Checking /etc/shorewall/masq...
Checking MAC Filtration -- Phase 1...
Checking /etc/shorewall/rules...
Checking /etc/shorewall/conntrack...
Checking MAC Filtration -- Phase 2...
Applying Policies...
Checking /usr/share/shorewall/action.Reject for chain Reject...
Checking /usr/share/shorewall/action.Broadcast for chain Broadcast...
Checking /usr/share/shorewall/action.Drop for chain Drop...
Checking /etc/shorewall/stoppedrules...
Shorewall configuration verified

The shorewall rules are also fine. And is obvious because I can access the web server form the outside, but only from my other public IP.

I don’t see what is going on here. Please give some advice.

Thank you.

enzoturri · November 10, 2016, 7:36pm

Hi @Carlos_Estrada
sorry for the late reply

test as suggested by @giacomo

and post it
.we seek the solution together with the community

Carlos_Estrada · November 14, 2016, 6:17pm

Hi

The problem still persists. It occurs once or twice a week. This is taken one minute after it starts to fail:

`[root@gate ~]# tail -f /var/log/messages
Nov 14 11:47:18 gate esmith::event[7662]: Event: nethserver-mail-filter-save SUCCESS
Nov 14 11:54:33 gate clamd: SelfCheck: Database status OK.
Nov 14 11:55:02 gate systemd: Removed slice user-0.slice.
Nov 14 11:55:02 gate systemd: Stopping user-0.slice.
Nov 14 11:56:39 gate sshd[8014]: Accepted publickey for root from 192.168.1.61 port 42132 ssh2: RSA 15:96:2d:1a:1f:32:9e:76:16:06:3e:b3:11:fc:98:3e
Nov 14 11:56:39 gate systemd: Created slice user-0.slice.
Nov 14 11:56:39 gate systemd: Starting user-0.slice.
Nov 14 11:56:39 gate systemd-logind: New session 548 of user root.
Nov 14 11:56:39 gate systemd: Started Session 548 of user root.
Nov 14 11:56:39 gate systemd: Starting Session 548 of user root.
Nov 14 11:57:20 gate clamd[11144]: SelfCheck: Database modification detected. Forcing reload.
Nov 14 11:57:20 gate clamd: SelfCheck: Database modification detected. Forcing reload.
Nov 14 11:57:21 gate clamd[11144]: Reading databases from /var/lib/squidclamav
Nov 14 11:57:21 gate clamd: Reading databases from /var/lib/squidclamav
Nov 14 11:57:22 gate clamd: Database correctly reloaded (167630 signatures)
Nov 14 11:57:22 gate clamd[11144]: Database correctly reloaded (167630 signatures)`


`[root@gate ~]# tail -f /var/log/firewall.log
Nov 14 11:57:11 gate kernel: Shorewall:net2fw:DROP:IN=em1 OUT= MAC=00:26:b9:86:1f:e3:90:17:ac:be:7e:58:08:00 SRC=118.43.134.172 DST=138.117.7.184 LEN=40 TOS=0x00 PREC=0x00 TTL=45 ID=11667 PROTO=TCP SPT=32874 DPT=23 WINDOW=44354 RES=0x00 SYN URGP=0 
Nov 14 11:57:11 gate kernel: Shorewall:net2fw:DROP:IN=em1 OUT= MAC=00:26:b9:86:1f:e3:90:17:ac:be:7e:58:08:00 SRC=118.43.134.172 DST=138.117.7.184 LEN=40 TOS=0x00 PREC=0x00 TTL=45 ID=11667 PROTO=TCP SPT=32874 DPT=23 WINDOW=44354 RES=0x00 SYN URGP=0 
Nov 14 11:57:16 gate kernel: Shorewall:net2fw:DROP:IN=em1 OUT= MAC=00:26:b9:86:1f:e3:90:17:ac:be:7e:58:08:00 SRC=177.34.147.20 DST=138.117.7.184 LEN=40 TOS=0x00 PREC=0x00 TTL=48 ID=13300 PROTO=TCP SPT=46358 DPT=23 WINDOW=38974 RES=0x00 SYN URGP=0 
Nov 14 11:57:18 gate kernel: Shorewall:net2fw:DROP:IN=em1 OUT= MAC=00:26:b9:86:1f:e3:90:17:ac:be:7e:58:08:00 SRC=118.43.134.172 DST=138.117.7.184 LEN=40 TOS=0x00 PREC=0x00 TTL=45 ID=11667 PROTO=TCP SPT=32874 DPT=23 WINDOW=44354 RES=0x00 SYN URGP=0 
Nov 14 11:57:27 gate kernel: Shorewall:net2fw:DROP:IN=em1 OUT= MAC=00:26:b9:86:1f:e3:90:17:ac:be:7e:58:08:00 SRC=118.43.134.172 DST=138.117.7.184 LEN=40 TOS=0x00 PREC=0x00 TTL=45 ID=11667 PROTO=TCP SPT=32874 DPT=23 WINDOW=44354 RES=0x00 SYN URGP=0 
Nov 14 11:57:39 gate kernel: Shorewall:net2fw:DROP:IN=em1 OUT= MAC=00:26:b9:86:1f:e3:90:17:ac:be:7e:58:08:00 SRC=118.43.134.172 DST=138.117.7.184 LEN=40 TOS=0x00 PREC=0x00 TTL=45 ID=11667 PROTO=TCP SPT=32874 DPT=23 WINDOW=44354 RES=0x00 SYN URGP=0 
Nov 14 11:57:48 gate kernel: Shorewall:net2fw:DROP:IN=em1 OUT= MAC=00:26:b9:86:1f:e3:90:17:ac:be:7e:58:08:00 SRC=118.43.134.172 DST=138.117.7.184 LEN=40 TOS=0x00 PREC=0x00 TTL=45 ID=11667 PROTO=TCP SPT=32874 DPT=23 WINDOW=44354 RES=0x00 SYN URGP=0 
Nov 14 11:57:49 gate kernel: Shorewall:net2fw:DROP:IN=em1 OUT= MAC=00:26:b9:86:1f:e3:90:17:ac:be:7e:58:08:00 SRC=118.43.134.172 DST=138.117.7.184 LEN=40 TOS=0x00 PREC=0x00 TTL=45 ID=11667 PROTO=TCP SPT=32874 DPT=23 WINDOW=44354 RES=0x00 SYN URGP=0 
Nov 14 11:57:49 gate kernel: Shorewall:net2fw:DROP:IN=em1 OUT= MAC=00:26:b9:86:1f:e3:90:17:ac:be:7e:58:08:00 SRC=118.43.134.172 DST=138.117.7.184 LEN=40 TOS=0x00 PREC=0x00 TTL=45 ID=11667 PROTO=TCP SPT=32874 DPT=23 WINDOW=44354 RES=0x00 SYN URGP=0 
Nov 14 11:57:50 gate kernel: Shorewall:net2fw:DROP:IN=em1 OUT= MAC=00:26:b9:86:1f:e3:90:17:ac:be:7e:58:08:00 SRC=118.43.134.172 DST=138.117.7.184 LEN=40 TOS=0x00 PREC=0x00 TTL=45 ID=11667 PROTO=TCP SPT=32874 DPT=23 WINDOW=44354 RES=0x00 SYN URGP=0 
Nov 14 11:57:52 gate kernel: Shorewall:net2fw:DROP:IN=em1 OUT= MAC=00:26:b9:86:1f:e3:90:17:ac:be:7e:58:08:00 SRC=118.43.134.172 DST=138.117.7.184 LEN=40 TOS=0x00 PREC=0x00 TTL=45 ID=11667 PROTO=TCP SPT=32874 DPT=23 WINDOW=44354 RES=0x00 SYN URGP=0 
Nov 14 11:57:52 gate kernel: Shorewall:net2fw:DROP:IN=em1 OUT= MAC=00:26:b9:86:1f:e3:90:17:ac:be:7e:58:08:00 SRC=118.43.134.172 DST=138.117.7.184 LEN=40 TOS=0x00 PREC=0x00 TTL=45 ID=11667 PROTO=TCP SPT=32874 DPT=23 WINDOW=44354 RES=0x00 SYN URGP=0 
`


`[root@gate ~]# shorewall check
Checking using Shorewall 5.0.8.2...
Processing /etc/shorewall/params ...
Processing /etc/shorewall/shorewall.conf...
Loading Modules...
Checking /etc/shorewall/zones...
Checking /etc/shorewall/interfaces...
Determining Hosts in Zones...
Locating Action Files...
Checking /etc/shorewall/policy...
Running /etc/shorewall/initdone...
Adding Anti-smurf Rules
Adding rules for DHCP
Checking TCP Flags filtering...
Checking Kernel Route Filtering...
Checking Martian Logging...
Checking /etc/shorewall/tcinterfaces...
Checking /etc/shorewall/tcpri...
Checking /etc/shorewall/masq...
Checking MAC Filtration -- Phase 1...
Checking /etc/shorewall/rules...
Checking /etc/shorewall/action.NFQBY for chain NFQBY...
Checking /etc/shorewall/conntrack...
Checking MAC Filtration -- Phase 2...
Applying Policies...
Checking /usr/share/shorewall/action.Reject for chain Reject...
Checking /usr/share/shorewall/action.Broadcast for chain Broadcast...
Checking /usr/share/shorewall/action.Drop for chain Drop...
Checking /etc/shorewall/stoppedrules...
Shorewall configuration verified`



`[root@gate ~]# grep -i DNAT /etc/shorewall/rules
DNAT-    net    192.168.1.44:443    tcp    443    -    138.117.7.185
DNAT-    net    192.168.1.47:80    tcp    80    -    138.117.7.184
DNAT-    net    192.168.1.47:443    tcp    443    -    138.117.7.184
DNAT-    net    192.168.1.33:7001    tcp    7001    -    138.117.7.185
DNAT-    net    192.168.1.33:7002    tcp    7002    -    138.117.7.185
DNAT-    net    192.168.1.47:993    tcp    993    -    138.117.7.184
DNAT-    net    192.168.1.47:465    tcp    465    -    138.117.7.184
DNAT-    net    192.168.1.44:80    tcp    80    -    138.117.7.185`

I don’t see any problem there.

I have an automatic monitor which tells me when my site is down, so I can know when this problem is happening. The only way I have found to fix it (temporarily) is this:

Delete the alias address
Edit the main address. Change the address to the one of the alias.
Edit de main address. Change the address to normal.
Create the alias with it’s normal address.

It is fixed immediately after I follow this steps, but it happens again 5 or 6 days after that.

I don’t see any reason for this to happen. I’m also planning on eliminating the alias, but I need to do a special configuration to some servers.

If you have an idea please let me know.

Thank you.

filippo_carletti · November 15, 2016, 9:52am

Could you please check the connection when your monitor tells you that the port forward is not working?
Something like a tcpdump running on your external interface and you trying to access the service.

Valeriy · June 3, 2017, 8:18pm

I configured port forwarding for port 3389. Everything works. But port 32348 does not open, I do everything the same as for 3389. What could be the problem?

Valeriy · June 4, 2017, 6:09pm

Help me solve the problem.

enzoturri · June 6, 2017, 8:10pm

Hi @Valeriy,
You’ve tried tracking traffic as suggested by @filippo_carletti?

e.g.
tcpdump -i your-red-interface 'port 32874'

Some ideas:
Verify locally if you access the service on the destination machine.
Checks if forwarding port 32874 traffic to port 3389 works
The port is TCP or UDP
Create a firewall rule for port 32874

Valeriy · June 7, 2017, 5:30pm

I mean, I have rule number 1 for port 3389 and it works. I made another rule just replaced the port by 32874. And rule # 2 does not work.

douglasdiasn · August 21, 2017, 9:44am

Hi @Valeriy, I was having the same problem, I only managed to resolve after adding the rule directly shorewall.

Valeriy · August 28, 2017, 3:02pm

Can you write how you did it?

douglasdiasn · August 28, 2017, 3:33pm

Certainly!

Go to / etc / shorewall
Edit the rules file

Include the rule in this file, I put it after the SSHD rule
ACCEPT net $ FW (tcp or udp) (port number)

Save the file and exit
Restart the shorewall service
/etc/init.d/shorewall restart

Then check if the door is open on Iptables
Iptables -L | Grep portNumber

Check any external address or use the site http://www.yougetsignal.com/tools/open-ports/

Any questions please contact us.

etino · September 14, 2017, 3:28pm

Hello guys!

I’m back after a while in this amazing place!

I don’t know for how many time, but now I’m happy to be here again with you.

I’m running two Nethserver (6.9) installation (one as firewall role and the other as fileserver for the network) and I’m stubled in the same issue presented by @Carlos_Estrada.

I’ve followed the gread suggestions gives by @filippo_carletti, @giacomo, @enzoturri and @douglasdiasn in the thread and I’ve made the following steps without solving the problem.

This is the diagram of my network.

In the Nethserver Firewall I’ve cofigurated this Port Forwarding Rule

Namely: the port forwording of the 2121 public port to the 21 port of the FileServer (configurated with ftp enabled)

Then, before starting the check via yougetsignal.com tool, I’ve open three console for monitoring the connection:

One console on the firewall with tcpdump listening on port 2121
[root@fw ~]# tcpdump -i eth1 'port 2121'
Another console on the firewall monitoring firewall.log
[root@fw ~]# tail -f /var/log/firewall.log | grep DPT=2121
A console on fileserver with tcpdump listening on the standard ftp port
[root@fileserver ~]# tcpdump -i eth0 'port 21'

Well… the result is that:

I see the tcp traffic on the firewall port 2121, this is a part of the log

16:41:26.765800 IP 198.199.98.246.45482 > bb.bb.bb.99.scientia-ssdb: Flags [S], seq 2146193354, win 14600, options [mss 1440,sackOK,TS val 4245816580 ecr 0,nop,wscale 8], length 0 16:41:27.763137 IP 198.199.98.246.45482 > bb.bb.bb.99.scientia-ssdb: Flags [S], seq 2146193354, win 14600, options [mss 1440,sackOK,TS val 4245816830 ecr 0,nop,wscale 8], length 0 16:41:27.764842 IP 198.199.98.246.45486 > bb.bb.bb.99.scientia-ssdb: Flags [S], seq 2210218090, win 14600, options [mss 1440,sackOK,TS val 4245816830 ecr 0,nop,wscale 8], length 0 16:41:28.762467 IP 198.199.98.246.45486 > bb.bb.bb.99.scientia-ssdb: Flags [S], seq 2210218090, win 14600, options [mss 1440,sackOK,TS val 4245817080 ecr 0,nop,wscale 8], length 0

The firewall doesn’t log any DROP action in the firewall.log (at this point I suppose to see some kind on traffic on the tcpdump on the FileServer…)
The tcpdump command on port 21 of the server doesn’t log nothing! (Damn!)

And the result of the public port testing tool is that the port is closed…

Supposing that this is the way to check the path of the port forwarding connection… I haven’t solved the problem, but I hope in your help to find where is the issue.

Thank you in advance

filippo_carletti · September 14, 2017, 3:49pm

In firewall.log, look for DPT=21, as DNAT is done as soonas a packet enters the system (ok, I simplify, see here for the full story: https://en.wikipedia.org/wiki/Netfilter#/media/File:Netfilter-packet-flow.svg).

You can trace a packet:

set LOG_BACKEND=LOG in /etc/shorewall/shorewall.conf
shorewall restart
shorewall iptrace -d <ftp_server> --dport 21
grep TRACE /var/log/messages

Use shorewall restart to disable tracing.

etino · September 14, 2017, 5:20pm

Well… As I’ve supposed, it was just a foolish thing!

I’ve made two error in my configuration:

In the forwarding rule I’ve picked up a wrong alias!
Than I’ve discovered that in the File Server the FTP service was enabled only for green network.

But all this stuffs are been simple to find with your help… thank you so much!

I wanna give to you only a feedback about your on this command:

[root@fw ~]# shorewall iptrace -d --dport 21
Bad argument `21'
Try `iptables -h' or 'iptables --help' for more information.
Bad argument `21'
Try `iptables -h' or 'iptables --help' for more information.

I’m not confident with this command and I haven’t found useful information on google… so I felt to change the parameters in this way:

# shorewall iptrace -d 198.199.98.246 (the public source ip)

And It works!
Then I’ve found useful information in the TRACE log generated with your instructions to solve my problem… but I don’t know exactly how…

If you have some useful resource on this tool, I will appreciate it

Read you soon… (but also seen)