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 ...
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.
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
Thanks for going the extra mile. This appears to be "My Bad". In their infinite wisdom, Netgear changed the way information is presented in the Debug capture file between the original WiFi5 Orbi product and the newer Orbi models. The WiFi5 debug file has two pcap files: lan.pcap and wan.pcap.
I do not have an 850 product, but do have an RBR750 router. The Debug file collected from the RBR750 contains br.pcap and eth0.pcap
br.pcap is a capture of packets on the internal ethernet interface.
eth0.pcap is a capture of packets on the external (wan) ethernet interface.
This appears to match your RBR850.
If you look at the eth0.pcap file every packet coming from the router will have the public IP address of the router. If those packets are examined, it will show that the "port" associated with each is artificial (i.e. created by the NAT process).
The point of the matter remains the same. The "port" contained in those Orbi log entries is irrelevant. What matters is that someone has discovered that a port on your 850 router is accepting connection attempts from the internet and sending them to a device on the LAN. It is up to the LAN device to accept or deny access.
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.