I am using a CRS109-8G-1S-2HnD. Port 1 is configured as WAN, with static IP assigned.
On port 2 I have a PLC connected, the is awainting a modbus connection. I have setup port forwarding on port 502, in order able to connect a device located in the WAN network to my PLC.
I can ping the router from the WAN network, but when trying to establish a modbus connection I get a timeout.
Could anyone help me, please?
Is there anything else I must do for the connection to be bidirectional on the same port?
Make sure your firewall’s filter rules aren’t blocking the packets.
Are you attempting a unicast connection or a multicast connection? Multicast is a different animal and requires you to turn on things like IGMP proxy or PIM.
A generic rule that allows all pinholes would be this:
/ip firewall filter add chain=forward connection-nat-state=dstnat action=accept
Be sure this rule falls before any “drop all” rules in the forward chain.
If you want to be more specific, then instead of matching the nat state, use the dst-address=internal.ip.of.PLC protocol=tcp dst-port=xxxxx
filter forward chain comes after dstnat chain, so the rule should look for the true internal IP of the plc - and the true internal port number if you’re also mapping a different external port number as well.
I actually have a simillar issue, athough somewhat different.
In my case in the company office we have a couple computers, and a bunch of PLC-s.
We just upgraded our router from an RB2011 to an RB4011.
In case of the RB2011 everything was working, but in case of the new one it doesn’t. The config of the new is almost identical to the old, so not sure what the problem here is.
We added some things here and there, but not much.
Issue: We connect via VPN to the network (we use both L2TP and PPTP). In case of the old router, we could do almost everything with the PLCs.
With the new router, ping works, upload and webserver works on ports 80 and 443, but ModbusTCP connection on port 502 doesn’t work. Modbus software (Modscan) responses with “TCP connection terminated”, when trying to connect.
What should I check for? I can post the config here if needed.
In general, the firewall rules. In particular, it depends on the scenario. From your description I imply that there should be no NAT between the PLC controller and the PLCs themselves, i.e. that the controller is told to connect to the actual address of any of the PLCs and to TCP port 502 and it should connect to it - no port forwarding needed. As you say that “ping and web access works”, does it mean ping from the machine running the PLC controller to the addresses of the PLCs, and access from a browser running on the machine running the PLC controller to the web servers running on the PLCs works as well? If so, there must be permissive rules for access to TCP ports 80 and 443 in the PLC’s subnet (or the individual PLCs, or an address list) which are missing for access to TCP port 502.
So check the firewall rules first; if you cannot see anything, follow the advice in my automatic signature.
Ok, I must clear up some things: The Modbus connection is between the PC and PLC. The PC is running some Modbus software, and tries to coommunicate with the PLC via VPN.
As said, it worked before, not working now. Firewall rules are transfered by exporting them from the old router and uploading this section of the .rsc, to save some manual work
Checked at least 10 times, by having Winboxed with both routers, on 2 separate screens, so this is checked.
Can it be a NAT issue?
The main network is …124.0/22. However the Router, all DHCP and VPN IPs are given from …126.0/24, the PLCs are on static IPs on …125.0/24. Can this be a problem?
It should not… because ping and the others work, but I’m not very experienced with the nuances of MikroTik equipment.
By the way, if someone phisically in the office tries to connect to use Modbus it just works.
If pings on the exact same path like the modbus connection is established, it must be a firewall issue or possibly an MTU one. Post the export of the config as per my automatic signature.
After the rebooting of the router, almost all of the PLC devices “came to life”. There is one device left with the issue, but my colleauges think it could be on the device end, so this is being checked.
I did not try to reboot the router beforehand, mainly 'cause it is the main router, has been running since the install, it was tough to coordinate this with all the people, when they will loose access.
Anyway it is somewhat fixed, not sure what caused the issue.
I placed some Mangles to monitor the port trafic, and seems to be OK now.
