How to restrict SSH access to a TP-Link router to trusted IPs

¿How to restrict SSH access to a TP-Link router to trusted IPs? Controlling who can access your network via SSH is not a whim, it's an essential layer of security. Allow access only from trusted IP addresses It reduces the attack surface, slows down automatic scans, and prevents constant intrusion attempts from the Internet.

In this practical and comprehensive guide you will see how to do it in different scenarios with TP-Link equipment (SMB and Omada), what to consider with ACL rules and whitelists, and how to verify that everything is properly closed. We integrate additional methods such as TCP Wrappers, iptables, and best practices so you can secure your environment without leaving any loose ends.

Why limit SSH access on TP-Link routers

Exposing SSH to the internet opens the door to massive sweeps by already curious bots with malicious intent. It's not uncommon to detect port 22 accessible on the WAN after a scan, as has been observed in [examples of SSH]. critical failures in TP-Link routers. A simple nmap command can be used to check if your public IP address has port 22 open.: executes something like this on an external machine nmap -vvv -p 22 TU_IP_PUBLICA and check if "open ssh" appears.

Even if you use public keys, leaving port 22 open invites further exploration, testing other ports, and attacking management services. The solution is clear: deny by default and enable only from allowed IPs or ranges.Preferably fixed and controlled by you. If you don't need remote management, disable it completely on the WAN.

In addition to exposing ports, there are situations where you might suspect rule changes or anomalous behavior (for example, a cable modem that starts to "drop" outgoing traffic after a while). If you notice that ping, traceroute, or browsing are not getting past the modem, check the settings, firmware, and consider restoring factory settings. and close everything you don't use.

Mental model: block by default and create a whitelist

The winning philosophy is simple: default deny policy and explicit exceptionsOn many TP-Link routers with an advanced interface, you can set a Drop-type remote ingress policy in the firewall, and then allow specific addresses on a whitelist for management services.

On systems that include "Remote Input Policy" and "Whitelist rules" options (on Network - Firewall pages), Drop brand in remote entry policy And add to the whitelist the public IPs in CIDR format XXXX/XX that should be able to reach the configuration or services like SSH/Telnet/HTTP(S). These entries can include a brief description to avoid confusion later.

It is crucial to understand the difference between mechanisms. Port forwarding (NAT/DNAT) redirects ports to LAN machinesWhile "Filtering rules" control WAN-to-LAN or inter-network traffic, the firewall's "Whitelist rules" govern access to the router's management system. Filtering rules do not block access to the device itself; for that, you use whitelists or specific rules regarding incoming traffic to the router.

To access internal services, port mapping is created in NAT and then it is limited who can reach that mapping from outside. The recipe is: open the necessary port and then restrict it with access control. that allows only authorized sources to pass through and blocks the rest.

SSH from trusted IPs on TP-Link SMB (ER6120/ER8411 and similar)

In SMB routers such as TL-ER6120 or ER8411, the usual pattern for advertising a LAN service (e.g., SSH on an internal server) and limiting it by source IP is two-phase. First, the port is opened with a Virtual Server (NAT), and then it is filtered with Access Control. based on IP groups and service types.

Phase 1 – Virtual Server: go to Advanced → NAT → Virtual Server and creates an entry for the corresponding WAN interface. Configure external port 22 and point it to the server's internal IP address (for example, 192.168.0.2:22)Save the rule to add it to the list. If your case uses a different port (e.g., you've changed SSH to 2222), adjust the value accordingly.

Phase 2 – Service type: enter Preferences → Service Type, create a new service called, for example, SSH, select TCP or TCP/UDP and define the destination port 22 (the source port range can be 0–65535). This layer will allow you to reference the port cleanly in the ACL.

Phase 3 – IP Group: go to Preferences → IP Group → IP Address and add entries for both the allowed source (e.g. your public IP or a range, named "Access_Client") and the destination resource (e.g. "SSH_Server" with the server's internal IP). Then associate each address with its corresponding IP Group within the same menu.

Phase 4 – Access control: in Firewall → Access Control Create two rules. 1) Allow Rule: Allow policy, newly defined "SSH" service, Source = IP group "Access_Client" and destination = "SSH_Server". Give it ID 1. 2) Blocking Rule: Block policy with source = IPGROUP_ANY and destination = “SSH_Server” (or as applicable) with ID 2. This way, only the trusted IP or range will go through the NAT to your SSH; the rest will be blocked.

The order of evaluation is vital. Lower IDs take priorityTherefore, the Allow rule must precede (lower ID) the Block rule. After applying the changes, you will be able to connect to the router's WAN IP address on the defined port from the allowed IP address, but connections from other sources will be blocked.

Model/firmware notes: The interface may vary between hardware and versions. TL-R600VPN requires hardware v4 to cover certain functionsAnd on different systems, the menus may be relocated. Even so, the flow is the same: service type → IP groups → ACL with Allow and Block. Don't forget save and apply for the rules to come into effect.

Recommended verification: From the authorized IP address, try ssh usuario@IP_WAN and verify access. From another IP address, the port should become inaccessible. (connection that doesn't arrive or is rejected, ideally without a banner to avoid giving clues).

ACL with Omada Controller: Lists, States, and Example Scenarios

If you manage TP-Link gateways with Omada Controller, the logic is similar but with more visual options. Create groups (IP or ports), define gateway ACLs, and organize the rules to allow the bare minimum and deny everything else.

Lists and groups: in Settings → Profiles → Groups You can create IP groups (subnets or hosts, such as 192.168.0.32/27 or 192.168.30.100/32) and also port groups (for example, HTTP 80 and DNS 53). These groups simplify complex rules by reusing objects.

Gateway ACL: on Configuration → Network Security → ACL Add rules with LAN→WAN, LAN→LAN or WAN→LAN direction depending on what you want to protect. The policy for each rule can be Allow or Deny. and the order determines the actual result. Check "Enable" to activate them. Some versions allow you to leave rules prepared and disabled.

Useful cases (adaptable to SSH): allow only specific services and block the rest (e.g., Allow DNS and HTTP and then Deny All). For management whitelists, create Allow from Trusted IPs to the "Gateway Administration Page" and then a general deny from the other networks. If your firmware has that option. BidirectionalYou can automatically generate the inverse rule.

Connection status: ACLs can be stateful. The common types are New, Established, Related, and Invalid"New" handles the first packet (e.g., SYN in TCP), "Established" handles previously encountered bidirectional traffic, "Related" handles dependent connections (such as FTP data channels), and "Invalid" handles anomalous traffic. It's generally best to keep the default settings unless you require extra granularity.

VLAN and segmentation: Omada and SMB routers support unidirectional and bidirectional scenarios between VLANsYou can block Marketing→R&D but allow R&D→Marketing, or block both directions and still authorize a specific administrator. The LAN→LAN direction in the ACL is used to control traffic between internal subnets.

Additional methods and reinforcements: TCP Wrappers, iptables, MikroTik and classic firewall

In addition to the router's ACLs, there are other layers that should be applied, especially if the SSH destination is a Linux server behind the router. TCP Wrappers allows filtering by IP with hosts.allow and hosts.deny on compatible services (including OpenSSH in many traditional configurations).

Control files: if they don't exist, create them with sudo touch /etc/hosts.{allow,deny}. Best practice: deny everything in hosts.deny and explicitly allows it in hosts.allow. For example: in /etc/hosts.deny Pon sshd: ALL and in /etc/hosts.allow Add sshd: 203.0.113.10, 198.51.100.0/24Thus, only those IPs will be able to reach the server's SSH daemon.

Custom iptables: If your router or server allows it, add rules that only accept SSH from specific sources. A typical rule would be: -I INPUT -s 203.0.113.10 -p tcp --dport 22 -j ACCEPT followed by a default DROP policy or a rule that blocks the rest. On routers with a tab of Custom rules You can inject these lines and apply them with "Save & Apply".

Best practices in MikroTik (applicable as a general guide): change default ports if feasible, deactivate Telnet (use only SSH), use strong passwords or, better yet, key authenticationLimit access by IP address using the firewall, enable 2FA if the device supports it, and keep the firmware/RouterOS up to date. Disable WAN access if you don't need itIt monitors failed attempts and, if necessary, applies connection rate limits to curb brute force attacks.

TP-Link Classic Interface (Older Firmware): Log in to the panel using the LAN IP address (default 192.168.1.1) and admin/admin credentials, then go to Security → FirewallEnable the IP filter and choose to have unspecified packets follow the desired policy. Then, in IP Address Filtering, press "Add new" and define which IPs can or cannot use the service port on the WAN (for SSH, 22/tcp). Save each step. This allows you to apply a general deny and create exceptions to allow only trusted IPs.

Block specific IPs with static routes

In some cases it is useful to block outgoing to specific IPs to improve stability with certain services (such as streaming). One way to do this on multiple TP-Link devices is through static routing., creating /32 routes that avoid reaching those destinations or direct them in such a way that they are not consumed by the default route (support varies by firmware).

Recent models: go to the tab Advanced → Network → Advanced Routing → Static Routing and press "+ Add". Enter "Network Destination" with the IP address to block, "Subnet Mask" 255.255.255.255, "Default Gateway" the LAN gateway (typically 192.168.0.1) and "Interface" LAN. Select "Allow this entry" and saveRepeat for each target IP address depending on the service you want to control.

Older firmwares: go to Advanced routing → Static routing list, press "Add new" and fill in the same fields. Activate route status and saveConsult your service's support to find out which IPs to treat, as these may change.

Verification: Open a terminal or command prompt and test with ping 8.8.8.8 (or the destination IP you have blocked). If you see "Timeout" or "Destination host unreachable"The blocking is working. If not, review the steps and restart the router for all the tables to take effect.

Verification, testing, and incident resolution

To verify that your SSH whitelist is working, try using an authorized IP address. ssh usuario@IP_WAN -p 22 (or the port you use) and confirm access. From an unauthorized IP address, the port should not offer service.. Uses nmap -p 22 IP_WAN to check the hot condition.

If something isn't responding as it should, check the ACL priority. The rules are processed sequentially, and those with the lowest ID win.A Deny above your Allow invalidates the whitelist. Also, check that the "Service Type" points to the correct port and that your "IP Groups" contain the appropriate ranges.

In the event of suspicious behavior (loss of connectivity after a while, rules that change on their own, LAN traffic that drops), consider update the firmwareDisable services you don't use (remote web/Telnet/SSH administration), change credentials, check MAC cloning if applicable, and ultimately, Restore to factory settings and reconfigure with minimal settings and a strict whitelist.

Compatibility, models, and availability notes

The availability of features (stateful ACLs, profiles, whitelists, PVID editing on ports, etc.) It may depend on the hardware model and versionIn some devices, such as the TL-R600VPN, certain capabilities are only available from version 4 onwards. The user interfaces also change, but the basic process is the same: blocking by default, define services and groups, allow from specific IPs and block the rest.

Within the TP-Link ecosystem, there are many devices involved in enterprise networks. Models cited in the documentation include T1600G-18TS, T1500G-10PS, TL-SG2216, T2600G-52TS, T2600G-28TS, TL-SG2210P, T2500-28TC, T2700G-28TQ, T2500G-10TS, TL-SG5412F, T2600G-28MPS, T1500G-10MPS, SG2210P, S4500-8G, T1500-28TC, T1700X-16TS, T1600G-28TS, TL-SL3452, TL-SG3216, T3700G-52TQ, TL-SG2008, T1700G-28TQ, T1500-28PCT, T2600G-18TS, T1600G-28PS, T2500G-10MPS, Festa FS310GP, T1600G-52MPS, T1600G-52PS, TL-SL2428, T1600G-52TS, T3700G-28TQ, T1500G-8T, T1700X-28TQamong others. Keep in mind that The offer varies by region. and some may not be available in your area.

To stay up to date, visit your product's support page, choose the correct hardware version, and check firmware notes and technical specifications with the latest improvements. Sometimes updates expand or refine firewall, ACL, or remote management features.

Close the SSH For all but specific IPs, properly organizing ACLs and understanding what mechanism controls each thing saves you from unpleasant surprises. With a default deny policy, precise whitelists, and regular verificationYour TP-Link router and the services behind it will be much better protected without giving up management when you need it.

Related article:

TP-Link faces critical failures in enterprise routers and growing regulatory pressure

Cristian Garcia

Passionate about technology since he was little. I love being up to date in the sector and, above all, communicating it. That is why I have been dedicated to communication on technology and video game websites for many years. You can find me writing about Android, Windows, MacOS, iOS, Nintendo or any other related topic that comes to mind.