IIS FTPS Port Reachable on LAN but not WAN

Question

I have an offsite Microsoft IIS FTPS host (x.74), listening on port 8443. IIS Version 6.2 build 9200, Windows server 2012 R2.

From my workstation, i can telnet x.74:8443. (workstation -> site 1 firewall -> host)

A service provider cannot telnet the same port. (NAT x.12:8443) (provider -> site 2 firewall -> site 1 firewall -> host)

both sites are company controlled and on the same WAN. service provider is stationed at site 2. NAT rule is at site 2. We can see the traffic on both site firewalls with appropriate source and destination, and traffic is accepted. So issue is most likely on server itself.

IIS logs on server do not show any attempts from ServiceProvider, but i can see my attempts. i've turned off server firewall and uninstalled antivirus to eliminate possible sources of block. we've tried adding NAT address to IIS site binding alongside physical server IP.

Would there be something i need to tweak on IIS (or elsewhere) to enable ServiceProvider to access the port?

Extra info: Most configurations were cloned from an identical server that communicates with the same ServiceProvider. need to shift service provider to site 2 due to shared services something something. (provider -> host) this configuration is working perfectly. no NAT. FTPS will be passive mode.

Answer 1

Issue was with the NAT rules, not IIS. Telnets helped solve that.

assuming service provider IP is x.10, they were trying to reach my IIS using NAT x.12. but, the NAT would forward the traffic with the original source IP of x.10.

site 1 has a direct connection to service provider (using same x.10 IP), that we are trying to migrate from, so traffic between IIS and service provider through the direct link is blocked.

problem was, when IIS tried to respond to service provider, it responded with original IP that it received, which would then attempt to route the response through the direct link (that is blocked) and not the desired link (through Site 2).

proposed solution was to forward the traffic with another NAT IP as the source IP, so IIS would send response to that NAT which would be routed through Site 2.

implemented solution was to have the IIS server in site 2 and skip all the routing chaos.

Incoming traffic route: provider -> site 2 firewall -> site 1 firewall -> host

Desired outgoing traffic route: host -> site 1 firewall -> site 2 firewall -> provider

Traffic route that caused the failure: host -> site 1 firewall -> provider

Solution: put host in site 2