Gisueppe, Rick,
This is resolved. It was as simple as changing the port.
Forgive the late reply but was awaiting the vendor side to make firewall change on their side and then test connection and confirm.
The takeaways here are:
1) I never stated at any point that the vendor was telneting to port 30001 -- this was a critical piece of information I omitted.
2) I had the idea that NAT port forwarding was concerned only with inbound connections, and only relevant to anything targeting the outside IP and port. My assumption was that since they were targeting 10.10.10.50, the static NAT entry ip nat inside source static tcp 10.10.10.50 30001 38.38.38.98 30001 extendable would be ignored. This turned out not to be the case for outbound traffic from inside to outside interface.
3) as Rick stated:
- packet capture on Gig0/0/0 should not see any traffic with your host source address or the telnet remote address. At the interface the telnet would be inside an encrypted ESP packet. I think packet capture on the vlan would be more productive.
This while true, was still helpful and revealing. That we DID see traffic where we should NOT was a good indicator for where the problem was.
4) sh ip nat trans was similarly also very useful in that we should NOT have had entries for 10.10.10.50:30001, but we did..
Thanks very much to you both for taking the time look at my configs and provide lots of expert insight.
