#traceroutecon #industrialnetworking #otnetworking #natninja | Josh Varghese
So, on that same Moxa NAT-102 that Alicia Lomas posted about, I discovered this morning Moxa recently released v.3.15 firmware for it which moved it to the same platform (MX-ROS) as their EDR line of products. I installed it on a lab unit to poke around a bit. While they didn't change the out-of-box defaults or wizard the way I wish they would, I did stumble across a new setting when creating NAT rules.
Auto Create Source NAT (1 below) - "Without enabling this item, only a DNAT rule will be created"
Those who have been to #TracerouteCon know that I simultaneously love NAT as a technology but generally dislike most of the UIs for configuring it. This is a good example of why the NAT UIs can be challenging.
Not to be confused with Double NAT (2 below), which itself adds a Source NAT translation on WAN to LAN traffic in my screenshot below...this new option creates an explicit LAN to WAN Source NAT for unsolicited traffic originating from LAN to WAN. What's wild about this is that LAN to WAN Source NAT happens automatically for stateful return traffic against this 1:1 NAT rule I'm creating but this explicit Source NAT is required for certain applications like Rockwell Automation Produce/Consume (Unicast) messaging across a NAT boundary. Prior to this firmware, I had to add this explicit Source NAT manually with a completely separate Advanced rule entry so this is a welcome addition, but I suspect it will create its fair share of confusion.
So...clear as mud? 🤣 I can already feel this one making the list for a future long form video with wireshark on two laptops showing what the Source and Destination IPs look like before and after crossing the NAT-102 with the various knobs below turned in varying positions. Y'all let me know in the comments if that sounds interesting or "no, please no."
#industrialnetworking #otnetworking #natninja