From your statements my understanding is that both internal and WAN networks use public IP addressing (because of the no NAT from internal to WAN).
Now, because you're speaking about the internal network as a secure network, I'm assuming that TL-ER6020 is denying/blocking all the traffic from WAN to internal, and maybe it permits connections through the WAN if they're initiated in the internal network.
Having said that, these are some generally used approaches:
Enable direct remote management securely: to do so effectively you should:
- Use secure protocols only (HTTPs, SSH, etc.)
- Block all the connections from WAN to the TL-ER6020, except the secure management protocol
- Restrict the source IP/s allowed to connect
- Use a very strong authentication mechanism (with SSH for instance, you should use RSA authentication key rather than password/passphrase)
If you connect to the remote device from a network with static IP/s, and your device supports these features, this is a feasible solution. Unfortunately, TL-ER6020 seems not able to do so.
Attack Surface Reduction by limiting remote connectivity to VPN service only. Worth to note that even the lock-down of the device with the exception of SSH, for instance, reduces the attack surface. The main advantages of VPN approach are:
- VPN servers/daemons/services are considered more secure and resilient than most of the other remote access services (Telnet is a clear example). Anyway, a good implementation of SSH or SSL would be strong as well.
- You can actually reduce the attack surface when you allow multiple services: for instance, if you allow FTP, HTTP and SSH through the VPN, you would expose only the VPN service to internet, effectively reducing the components you need to heavily maintain.
Back to your real world situation, given that option 1 seems not suitable for your device, you might go for a VPN.
Referring to "On a Cisco RV042, I had configured things so that I would PPTP into the router and then would be able to access the router via its internal IP. However, this router had NAT configured", if the assumption about your design are correct, you just need to start the VPN connection and then access the internal public IP of the router itself.
In other words, absence of NAT would just mean that you have to deal with the real (probably public) IPs you assigned to your internal network.