# Refused local port forward



## leonardorame (Jun 30, 2018)

Hi, need to access the web ui of a FreeNas server from home (server is very far away), but sadly I only forwarded the SSH port on the site's router.

I can connect to the SSH console of the server, but when I create a tunnel using `ssh -L 8080:127.0.0.1:80 myuser@host.ip.add.ress` and then try to connect from my browser pointing to http://127.0.0.1:8080 on the ssh console I get:


```
channel 4: open failed: administratively prohibited: open failed
channel 4: open failed: administratively prohibited: open failed
channel 4: open failed: administratively prohibited: open failed
channel 4: open failed: administratively prohibited: open failed
channel 4: open failed: administratively prohibited: open failed
channel 4: open failed: administratively prohibited: open failed
```

If I take a look at /var/log/auth.sh I have:


```
Jun 30 06:49:57 freenas sshd[4114]: refused local port forward: originator 192.168.0.109 port 54428, target 127.0.0.1 port 80
Jun 30 06:49:57 freenas sshd[4114]: refused local port forward: originator 192.168.0.109 port 54430, target 127.0.0.1 port 80
Jun 30 06:49:57 freenas sshd[4114]: refused local port forward: originator 192.168.0.109 port 54432, target 127.0.0.1 port 80
```

Here's my /conf/base/etc/ssh/sshd_config:


```
#    $OpenBSD: sshd_config,v 1.80 2008/07/02 02:24:18 djm Exp $
#    $FreeBSD: src/crypto/openssh/sshd_config,v 1.48 2008/08/01 02:48:36 des Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

# Note that some of FreeBSD's defaults differ from OpenBSD's, and
# FreeBSD has a few additional options.

#VersionAddendum FreeBSD-20080801

#Port 22
#Protocol 2
#AddressFamily any
ListenAddress 0.0.0.0
#ListenAddress ::

# Disable legacy (protocol version 1) support in the server for new
# installations. In future the default will change to require explicit
# activation of protocol 1
Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile    .ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# Change to yes to enable built-in password authentication.
PasswordAuthentication yes
PermitEmptyPasswords yes

# Change to no to disable PAM authentication
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'no' to disable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
#UsePAM yes

#AllowAgentForwarding yes
AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
PermitTunnel yes
#ChrootDirectory none

# no default banner path
#Banner none

# override default of no subsystems
Subsystem    sftp    /usr/libexec/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#    X11Forwarding no
#    AllowTcpForwarding no
#    ForceCommand cvs server
```

As you can see I have AllowTcpForwarding set to "yes".

Can anyone help me solve this?

Leonardo.


----------



## ShelLuser (Jun 30, 2018)

First of all: FreeNAS is not the same as FreeBSD and therefor not supported on these forums, see also this link:

PC-BSD, FreeNAS, NAS4Free, and all other FreeBSD Derivatives

The best place to ask questions like these is on their forums and/or mailinglists.

We are allowed to discuss it though, but do be sure you heed the warning in that link. Also for your own protection because there is no guarantee that something which works on FreeBSD will also work on FreeNAS.

I find your question a bit strange to be honest. What guarantees do I have that you're not someone trying to gain unauthorized access? See, you say that you only forwarded the SSH port on the router, but you're immediately trying to use port 8080 and apparently that does something as well? So you forwarded more ports 

Why didn't you state as much? What more ports have been forwarded?

Anyway, what I'd suggest you do is install a program such as www/links, this is a console browser, and then use that to connect to the routers webgui. That's probably the easiest solution.

The other, assuming that port 8080 is indeed usable, could be to set up a NAT. So incoming data on port 8080 gets forwarded to the router. For that you'd have to re-configure your firewall and I have no idea what firewall FreeNAS uses (FreeBSD provides three different firewalls).

Your SSH solution is most likely going to fail because although the data maybe forwarded to the router,  there's no way the router would be able to respond. To my understanding forwarding is just that: a form of re-routing. So no packets get changed. And that would mean that even if data gets sent to the router it remains to be seen that the router would be able to contact your machine to return that data.


----------



## leonardorame (Jun 30, 2018)

No, on the router I only forwarded the ssh port. The port 8080 is forwarded through the ssh tunnel I establish with ssh -L 8080:127.0.0.1:80.


----------



## ShelLuser (Jun 30, 2018)

leonardorame said:


> No, on the router I only forwarded the ssh port. The port 8080 is forwarded through the ssh tunnel I establish with ssh -L 8080:127.0.0.1:80.


So how do you expect to use that if you can't reach port 8080 from the outside?

I think you misunderstand what this forwarding does. It allows you to open a port on the server, 8080 in this case, and redirect incoming traffic to another destination. But that won't solve your problem if you can't reach the port from the outside. And since you only forwarded SSH (which usually means port 22) you wouldn't be able to access port 8080.

Therefor my suggestion is still to install something like Links and try your luck on the console.


----------



## leonardorame (Jun 30, 2018)

No no, no and no!, I think you are misunderstanding how ssh tunneling works. On many other servers I only enable SSH (forwarding the port 22 on the router to the port 22 on the FreeNAS or Linux server) then, using "ssh -L" from the client machine I can reach an internal port not open on the router, this is a very common method to reach services.


----------



## ronaldlees (Jun 30, 2018)

Reverse tunnel


----------



## leonardorame (Jun 30, 2018)

Yes ronaldlees, I know that should work, but I wonder why the approach I followed didn't work on this server but it does on many other servers I use.


----------



## ShelLuser (Jun 30, 2018)

This is also assuming that nothing isn't blocking SSH forwarding, which is perfectly possible. Especially considering the log entries you got.


----------



## leonardorame (Jun 30, 2018)

ShelLuser, yes that's why I ask here. I don't know where to check for those possible blockings. 

I must add the server has a brand new FreeNas installation, I only created a user (for non-root ssh login) and enabled SSH, that's all I configured on this server.


----------



## SirDice (Jul 2, 2018)

`ssh -L 8080:localhost:80 user@some.host`

This forwards localhost:8080 on the client to localhost:80 of some.host. I'm assuming some.host isn't your FreeNAS but some other machine that's on the edge of the network. And because some.host itself doesn't have anything listening on localhost:80 you get the messages you're seeing because you are forwarding to a closed port. 

So you need something like this:
`ssh -L 8080:internal.ip.of.freenas.host:80 user@some.host`
This forwards localhost:8080 on the client to internal.ip.of.freenas.host:80 _through_ some.host.


----------

