Good morning everyone! I've been troubleshooting an issue with my network setup and I'm encountering some challenges. My system consists of a private machine network with IP addresses in the 192.168.1.xxx range. I'm using a 1783-NATR to connect to the plant network with IP addresses in the 172.16.5.xxx range. The communication between the two networks is working smoothly. I'm trying to keep the HMI on the machine network and enable access to it from the LAN using a NAT rule for the VNC viewer, instead of adding a second Ethernet switch in the cabinet for the Plant LAN. The HMI is a Weintek eMT3105P and it successfully communicates with my PLC from both sides of the NATR. I can also ping the HMI from my PC while it's connected to either side of the NATR. However, I'm facing an issue where the VNC viewer on my PC is not able to connect to the HMI through the NAT module, even though all other communications are functioning correctly. Any insights on why the VNC viewer is not working over the NATR despite the successful connections on other fronts? I have confirmed that the VNC is operational on the HMI as I can access it from the machine network.
To the best of my knowledge, the 1:1 NAT feature on these devices does not include any TCP Port or protocol specific restrictions, allowing RSLinx, IGMP PING, and VNC to function seamlessly. While it is commonly said that "NAT is not routing," the 1783-NATR user manual (page 46) mentions the significance of setting the Default Gateway for devices on the Private side. According to the manual, the gateway address for any device on the private network that is being translated must be set to the 1783-NATR Private port address. This week, I am delving into a NAT system that was set up by others approximately five years ago, utilizing Stratix 5700. The configuration of NAT rules on these devices can be a bit more complex.
According to Ken Roach, the 1:1 NAT feature on these devices does not have any TCP port or protocol-specific filters, allowing RSLinx, IGMP PING, and VNC to function the same. While it is commonly known that "NAT is not routing," the user manual for the 1783-NATR (page 46) indicates the importance of matching the Default Gateway for devices on the Private side with the NATR module's Private Network IP address. This configuration enables successful Pings and communication between the PLC and HMI. However, issues arise when attempting to use VNC or download to the HMI over the NATR from the Plant LAN to the Private Network. Despite the Ping functioning well, the software does not connect and prompts to check IP addresses and connections. Therefore, I temporarily relocated the HMI to the Plant LAN to proceed without interruptions. The inconsistent functionality is puzzling, as I expected it to either work entirely or not at all. Additionally, I discovered that configuring a rule on the NATR to monitor a Plant LAN IP address results in an IP conflict when a device with that address is present on the Plant LAN, even if not physically connected to the private network. This situation is quite intriguing.
It has been quite some time since I last worked with a 1783-NATR router, but have you attempted configuring a custom rule to allow Port 5900 (VNC) through the web interface NAT settings?
Encountering similar issues with a newly installed machine on our floor, I found it easy to access AB equipment through the NATR. However, I faced difficulties with the Cognex cameras, MyCloud NAS, and other devices we needed to connect with. While I could ping everything, establishing a connection was a challenge. Upon realizing a discrepancy in the web interface from the manual, I discovered the option to create custom rules for each connection, allowing me to open the necessary TCP and UDP ports. Despite this, the Cognex Cameras required more than the 5 ports allowed, hindering complete access. However, I did manage to access their web page. The screenshots I provided were obtained from the Network Address Translation tab in the Device Manager Web-Interface. This issue seems to be specific to Product Revision 1.005 Build 50. To identify the ports in use, I utilized WireShark, uncovering common ones like port 80 for web interface, as well as undocumented ones for different operations.
It seems like you've done a thorough job in troubleshooting your issue, and it's curious that you can connect on other fronts except via the VNC Viewer. One possible issue could be the NAT translation rule for the VNC viewer; perhaps it's not correctly configured. Another issue may be related to the specific ports that the VNC viewer is using - perhaps they're not open or not being correctly forwarded through NATR. You might want to double-check these aspects. Additionally, ensure that there are no firewall settings blocking the VNC viewer's connection. Lastly, if nothing works, you may want to consider updating or reinstalling the VNC viewer software or checking for any known issues with the VNC viewer and your specific NATR or HMI model. Hope this helps!
Hello there! It's fascinating problem you're dealing with. Assuming that your NAT configurations and firewall permissions are all in check, I suspect the issue could be occurring at the VNC viewer level itself. For instance, some VNC viewers may not support NAT traversal inherently, causing connection failure. Secondly, could there be a non-standard port being used by the VNC viewer? The 1783-NATR module might not properly redirect uncommon ports, which might cause issues, and you may need to manually forward those ports in your settings. Lastly, consider checking any relevant settings on the HMI to ensure it isn't blocking access from the plant LAN IP range.
Hey there! It sounds like you have a very comprehensive setup and you've done some thorough troubleshooting. Given that other forms of communication are working through the NATR, excluding the VNC viewer, it leads me to believe that the issue might be with some firewall rules within your network. It's not uncommon for VNC-type connections to be blocked due to their potential security vulnerabilities. I'd recommend checking if there are any firewall rules on your private machine network or even on the PC you are using to access the HMI which might be blocking VNC traffic. Also, there could be specific settings in your NATR that manage the way it handles VNC connections. Make sure to double-check the documentation on that. Keep us posted!
✅ Work Order Management
✅ Asset Tracking
✅ Preventive Maintenance
✅ Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Answer: Answer: The issue could be related to specific VNC viewer settings, firewall configurations, or port forwarding rules within the NAT module that may need adjustment.
Answer: Answer: To troubleshoot VNC connectivity problems, you can start by checking the VNC viewer settings, verifying firewall rules, ensuring proper port forwarding is configured in the NAT module, and confirming that the HMI is accessible within the network.
Answer: Answer: Yes, to enable VNC viewer access through a NAT module, you may need to set up appropriate port forwarding rules in the NAT device to forward incoming VNC traffic to the internal IP address of the HMI on the machine network.
Answer: Answer: While successful communication between devices over a NAT module is a positive sign, specific VNC-related configurations such as port settings, network protocols, or authentication methods could still be causing the VNC viewer connectivity problem.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.