NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
Port forwarding allow other external ports on Orbi RBR850
I'm only forwarding one external port to internal port 22, however, the logs show various external ports forwarding to internal port 22. Those external ports have no entries in the "Port Forwarding / Port Triggering" section in the Orbi web admin page. Why is it allowing and how can I block?
Here are some log entries (removed non-related lines):
[LAN access from remote] from 183.91.14.197 port 37529 to 10.0.0.134 port 22 Monday, Jun 01,2026 16:39:42
[LAN access from remote] from 183.91.14.197 port 54174 to 10.0.0.134 port 22 Monday, Jun 01,2026 16:39:30
[LAN access from remote] from 183.91.14.197 port 3872 to 10.0.0.134 port 22 Monday, Jun 01,2026 16:39:19
[LAN access from remote] from 183.91.14.197 port 28671 to 10.0.0.134 port 22 Monday, Jun 01,2026 16:39:07
[LAN access from remote] from 183.91.14.197 port 13185 to 10.0.0.134 port 22 Monday, Jun 01,2026 16:38:54
[LAN access from remote] from 183.91.14.197 port 48296 to 10.0.0.134 port 22 Monday, Jun 01,2026 16:38:42
[LAN access from remote] from 183.91.14.197 port 24039 to 10.0.0.134 port 22 Monday, Jun 01,2026 16:38:30
[LAN access from remote] from 183.91.14.197 port 2803 to 10.0.0.134 port 22 Monday, Jun 01,2026 16:38:18
[LAN access from remote] from 183.91.14.197 port 64576 to 10.0.0.134 port 22 Monday, Jun 01,2026 16:38:06
[LAN access from remote] from 183.91.14.197 port 10676 to 10.0.0.134 port 22 Monday, Jun 01,2026 16:37:54
[LAN access from remote] from 183.91.14.197 port 45794 to 10.0.0.134 port 22 Monday, Jun 01,2026 16:37:42
[LAN access from remote] from 183.91.14.197 port 45558 to 10.0.0.134 port 22 Monday, Jun 01,2026 16:37:30
Someone is attempting to connect, for example, from 183.91.14.197 on 13722 which forwards to 10.0.0.134 on port 22 but the log may show a different external port so looks like someone connecting from 183.91.14.197 on 37529?
Someone was trying to connect from 183.91.14.197:13722 to <router ip>:22, and would therefore receive any replies on 183.91.14.197:13722
That same someone then tried again to connect from a different source port like 183.91.14.197:37529 And again, and again....
Nothing going wrong in the Orbi - it is doing exactly what you told it to do. That is to forward any inbound traffic with a destination port of 22 to 10.0.0.134.
A flood of requests suggests that these attempts were not successful - perhaps because they were attempting to guess the admin password, and didn't get it right. But still, using a VPN to connect instead of forwarding the port is a more secure approach.
11 Replies
Ok, I'm getting strange behavior with this forum website. Cannot post response directly to StephenB so posting below. Was not able to attach screenshots as it eternally says "Media upload in progress. Try again in a few months" despite trying it 5min, 30min and 60min later.
I was not able to find any entries in the Orbi log for port 13722 but then maybe it's so early in the logs that I no longer have.Ok that makes sense now, 183.91.14.197:13722 originally got a response from my system that it was open, then it proceeded to try all other possible ports, during which time I noticed.
Although, I have a good password and only allow SSH on that device open to port 13722, it an an EOL ReadyNAS, so I think I will keep it offline until I can implement some sort of firewall at the router level. I'd rather block traffic there rather than pass it to internal network. Thanks for thought of VPN, I think the QNAP may have capability to do that.
Thanks StephenBI do not recognize the source. The connection is only meant to be used by me for NAS to NAS backup. I’ve got a connection setup for SSH.
The ReadyNAS 314 showed account “root” was connected from 183.91.15.197 so I was concerned since it was an account from Vietnam - I am in the US.
What I don’t understand is how the Orbi can allow a connection from an external port which I did not specify. I use a non-standard port number to forward to 22.
Am I incorrectly interpreting the logs that connections are being made from the various external ports to internal port 22? Is this something I should not be worried about?
As others have commented, what the log is recording is that an application on a computer or router at 193.81.14.197 has attempted to open a connection to the port that you have forwarded to port 22 on the NAS and the NAS reports an attempt to log into the account "root". When an application attempts to open a connection, it typically generates a temporary port number for each connection. If the remote computer is connected to a LAN, then the router that created that LAN will use Network Address Translation (NAT) to create artificial "port numbers" for each connection attempt.
https://en.wikipedia.org/wiki/Network_address_translation
Somehow, someone (or some robot) has discovered that your router accepts connections on that port that you have forwarded.
It is up to the NAS to reject connections that are not wanted, or to require a password to connect.
There is an easy way to verify this phenomenon.
- Open the router "debug" page (http://orbilogin.net/debug.htm
- Enable the feature Enable LAN/WAN packet capture.
- Start a capture
- On any computer on your network, open a connection to some remote computer. For example, this site allows people to FTP files:
https://dlptest.com/ftp-test/
I happen to use FileZilla for FTP. There are other FTP apps. - After the connection is established, go back to the router debug page. Stop the packet capture. Save the capture file to your computer.
- Open the debug zip file and open the file wan.pcap using a pcap program, such as Wireshark (free for Windows)
- Notice that the connection will NOT come from your local computer and will NOT come from port 21 (FTP).
It will come from the public IP address of your router and from some random port number.
Oh, it doesn't look like two screenshots uploaded with my last response (doing this on a Mac)
I was able to do all steps but cannot identify an wan.pcap file. There are two files with pcap in the name: BR.pcap mape_log_tmp and eth4.pcap speedtest_result.log. I don't find any that correspond to wan.The Orbi is on firmware V7.2.8.2_5.1.18
So, if I undertand you... Someone is attempting to connect, for example, from 183.91.14.197 on 13722 which forwards to 10.0.0.134 on port 22 but the log may show a different external port so looks like someone connecting from 183.91.14.197 on 37529?
Below are files and directory contents of the downloaded Debug_log file from http://orbilogin.net/debug.htm
acos_watchdog_log_tmp info.txt
attach_util_log_tmp kmsg_old.log
auto_fw_upgrade_daily.log kmsg.log
auto_fw_upgrade_force.log knowndevices
basic_debug_log.txt log
BR.pcap mape_log_tmp
cloud_backend_log mtd18
critical_attach_log_tmp mtd20
d2d.zip mtd22
dbg_log_tmp mtd25
device_detect.log ntgrlog
devices oc_350_stuck.log
dhcpd_device_release OTP.log_tmp
dmesg.log soapc_log_tmp
eth4.pcap speedtest_result.log
flog tmp
heartbeat_log_tmp wireless-log1.txt
httpd_log_tmp
./flog:
ethernet_debug_log_old.txt ethernet_debug_log.txt
./log:
dnsmasq.log dnsmasq.log.1
./ntgrlog:
bd_logs core_files ntgr_debug_cmd_log
circle_logs dnsmasq.log partition_mount
cloud.log dnsmasq.log.1
configs log_seal
./ntgrlog/bd_logs:
bitdefender_logs.tar.gz storage.data
./ntgrlog/circle_logs:
vendortest.log
./ntgrlog/configs:
client2.conf network
cnss_diag nss
ddns nvram_wifi
device-info openvpn
dhcp6c_widev6_iapdonly.conf openvswitch
dhcp6c_widev6.conf qcacfg80211
dhcrelay repacd
dropbear resolv.conf
ecm ripd
firewall.conf ripd.conf
hostapd_cred_tmp.conf rpcd
hostapd-ath0.conf rstp
hostapd-ath01.conf server_tap.conf
hostapd-ath02.conf server_tun.conf
hostapd-ath03.conf skb_recycler
hostapd-ath1.conf ssid-steering
hostapd-ath11.conf sysstat
hostapd-ath12.conf system
hostapd-ath13.conf ubootenv
hostapd-ath14.conf udhcpd_resrv.conf
hostapd-ath2.conf udhcpd.conf
hyd udhcpd2.conf
hyd-guest.conf upnpd
hyd-lan.conf wifi-wps-enhc-extn.conf
igmpproxy wireless
lbd wsplcd
M.conf wsplcd-guest.conf
macsec wsplcd-lan.conf
minidump zebra.conf
./ntgrlog/core_files:
core.dal_service.10425.sig.11.RBR850.04_Sep_2025_09_16_41_DST.tar
core.dal_service.6358.sig.11.RBR850.04_Sep_2025_09_16_24_DST.tar
./ntgrlog/log_seal:
circle_status.txt lxc_start_armor-bd.log
csh.log lxc_start_spc-circle.log
d2d.zip lxc_stop_armor-bd.log
dal_ash.log lxc_stop_spc-circle.log
dalh.log Ra.log
dumpsm.log syslog.txt
fing_dil.log UpAgent.log
iptables_rule.log xagent.log
lighttpd
./ntgrlog/log_seal/lighttpd:
breakage_root.log breakage.log
./tmp:
aws_json_dir
./tmp/aws_json_dir:
aws_RBR850_0_pretty.json aws_RBR850_2_pretty.json
aws_RBR850_0.json aws_RBR850_2.json
aws_RBR850_1_pretty.json aws_RBR850.json
aws_RBR850_1.json
I'm only forwarding one external port to internal port 22, however, the logs show various external ports forwarding to internal port 22.
IP packets contain a source port and destination port.
The "from" port numbers are the source ports. The connection request from 183.91.15.197 is going to port 22. The destination (10.0.0.134) responds by sending a packet back to the source (37529, etc). KevinLiT is calling them "listener ports" because the source is listening on that port for the response.
Do you recognize the source? Does the destination server (10.0.0.134) have a strong password?
Did you disable uPnP when you set up your port forward configuration?
IP address shows a telecom in Vietnam?
Yes, uPnP was disabled a long time ago for better security. I looked up that the IP is in Vietnam which I do not recognize. That's why I was concerned.
Yes, uPnP was disabled a long time ago for better security. I looked up that the IP is in Vietnam which I do not recognize. That's why I was concerned.
The net here is that whenever you use port forwarding, you need to have good security in the device to which you are forwarding. That is particularly true for port 22 (which is normally used for ssh).
If this is just for your own remote access, it would be better to set up OpenVPN in the Orbi, and use that to reach your home network.
Hello ChocB ,
Welcome to the NETGEAR Community!
Understanding port numbers can be tedious due to the number of processes that are used to create instances such as sessions for TCP/UDP configurations. The ports mentioned are mainly listener ports used by your internal application. These ports cannot be blocked because they are dynamic ports that are used to fulfill a purpose. This is the reason why all of the mentioned ports are only logged once.
Best,
Kevin
NETGEAR Team
