Here's how I configured it:
- Configured two routers:
- RUT9a (LAN IP: 192.168.1.1; WAN IP: 192.168.10.100);
- RUT9b (LAN IP: 192.168.2.1; WAN IP: 192.168.1.200);
- Connected RUT9b's WAN port to RUT9a's LAN port;
- On RUT9a I configured a Port Forwarding rule that redirects SSH login attempts coming from WAN to RUT9b at IP address 192.168.1.200 (WAN);
- Enabled remote SSH access on RUT9b.
Here's how I tested it:
- Connected a PC to the 192.168.10.0/24 network (RUT9a WAN);
- SSH to 192.168.10.100 (RUT9a WAN IP) to see if the redirect works;
- When I confirmed that it works, I opened 32 Terminal windows on my PC; each ready to SSH to 192.168.10.100 (RUT9a WAN IP);
- Rebooted RUT9a;
- Waited 30 seconds and started launching SSH attempts from each Terminal window every 1 sec.;
- Tried this 5 times; each time I added 2 seconds to the original start time, i.e., the first time I started at 30 sec., second time at 32 sec., third time at 34 sec., etc.
The results:
I wasn't able to recreate the issue that you have described. I even repeated the experiment again by using a different Port Forward method (first time I configured it via the Port Forwarding page; the second time I used Custom Rules; both worked as expected.)
I recommend reviewing your rules to you see if everything is in order. Then maybe conduct some tests yourself and, if you can recreate the issue, download the Troubleshoot file and send it to me for analysis.
You can download the Troubleshoot file from the System → Administration → Troubleshoot page. However, take note that the Troubleshoot file should be downloaded after the issue occurs. Don't reboot the router before downloading the file! This way the error will not show up in the Troubleshoot logs.
Also, the Troubleshoot file contains a lot of information about your router. So you may want to consider removing information that you don't want to share (phone numbers, public IPs, etc.) before you send the file anywhere.