Windows Server 2003 R2: opening port 587

[Ichinisan]

I'm speaking with someone on the phone that's operating some kind of server on port 587 (not Microsoft Exchange, but something else). It's accessible from LAN devices, but an incoming connection from the WAN doesn't work.

The Apple AirPort Extreme is configured to forward incoming connections over port 587 to the server's internal IP. This does not work. The server allows incoming connections over port 587 from private IP addresses, but not from public IPs.

We also created a rule for 3389 and that works fine...connecting from a private LAN IP or an outside IP.

To test, we created a rule that translates external port 587 to internal port 3389 and I was able to access the Remote Desktop login screen with mstsc /v:[ip address]:587

...so it seems that something on the server is blocking non-LAN IPs from connecting over 587. I don't know anything about Windows Server. What should I have these guys check?

 

[seepy83]

Are you sure the ISP isn't blocking 587?

edit: nevermind...looks like you got 587 to forward to 3389.

What's the server/app running on 587? Unless you've got a firewall running on the 2k3 box that needs to be configured, I would think that maybe something in the application isn't configured correctly.

Load up wireshark and see if the traffic is making it as far as the 2k3 box.

 

[Ichinisan]

Are you sure the ISP isn't blocking 587?

Absolutely. I was able to connect to remote desktop through external port 587 (translated to internal port 3389).

Also, I work for the ISP.

To test, we created a rule that translates external port 587 to internal port 3389 and I was able to access the Remote Desktop login screen with mstsc /v:[ip address]:587

There's no doubt that port 587 reaches the customer's router. It's like there's some rule on the server machine that allows incoming connections from non-LAN IPs for port 3389, but does not allow incoming connections from non-LAN IPs for port 587.

I've done the same rule on my own AirPort Extreme, behind my cable modem at home (same ISP).

You can connect with mstsc /v:72.15.109.203:587 and see a login screen.

 

[seepy83]

Absolutely. I was able to connect to remote desktop through external port 587 (translated to internal port 3389).

Also, I work for the ISP.

Ya, sorry didn't pick that up the first read through...see my edit above.

 

[Ichinisan]

edit: nevermind...looks like you got 587 to forward to 3389.

What's the server/app running on 587?

Not sure. The customer is a chiropractic office. Some kind of software package they're using. They say it's accessible on port 587 through their LAN.

Unless you've got a firewall running on the 2k3 box that needs to be configured, I would think that maybe something in the application isn't configured correctly.

Yeah. Apparently, the Windows Firewall service isn't running. Makes me think there's a third-party firewall running. His control panel in Classic View doesn't have the Security Center icon (skips from "Scheduled Tasks" to "Sounds"). I had thought Security Center might be able to tell me which third-party firewall was running. He turned off AVG antivirus, but that didn't help. telnet [his public IP] 587 fails to connect.

Load up wireshark and see if the traffic is making it as far as the 2k3 box.

I haven't used wireshark before. Will it tell us if his LAN devices are *really* using port 587? I think they might actually be using port 25 or something.

 

[seepy83]

I haven't used wireshark before. Will it tell us if his LAN devices are *really* using port 587? I think they might actually be using port 25 or something.

Wireshark is a packet analyzer, so it will show you details for all data passing through a network interface. You would probably need to hold their hands to get it installed and configured to sniff on the right interface...then they would need to filter or look for the right conversation (which may be hard for a novice depending on how "chatty" their network is).

Something a little more basic...they could open a command prompt and run "netstat -ano" and then read the output to confirm that something is actually listening on port 587. if it's actually listening on 587, they should see something like this included in the output:

 Proto  Local Address          Foreign Address        State          
  TCP    0.0.0.0:587            0.0.0.0:0              LISTENING

 

[drebo]

Check the Windows Firewall. It's probably configured to only allow from internal.

It could also be that the application itself is configured to reject connections.

Port 587 is typically used as an alternate port for clients to connect on an SMTP server.

 

[Ichinisan]

Check the Windows Firewall. It's probably configured to only allow from internal.

The Windows Firewall service is not running. If there's a third-party firewall running, the guy can't find it.

It could also be that the application itself is configured to reject connections.

That's what I thought, but now I doubt that's what's happening. I had him try telnet [server's LAN IP] 587 from another Windows machine on the LAN and connection fails. I think the server is really listening on some other port number.

Port 587 is typically used as an alternate port for clients to connect on an SMTP server.

Yup. From another Windows machine on the same LAN, we tried telnet to 465 and 25 to see if those were listening. All failed.

I found that the Apple Airport really does have a DMZ option, but Apple calls it "Default Host" and it's in a different section from the port forwarding rules. They are going to try that. If it's remotely-accessible to their iPad app over the LTE connection, then I think it confirms their system is using some other port and not 587.

 

[Ichinisan]

As I suspected, his software was really listening on port 8221; not 587.

The iPad app had 2 profiles or something (I wasn't on-site to look at it). The internal profile connected on 8221 and the external profile was configured for 587. After we set both to 8221, it worked. After it was working, they tried some other function that gave hem specific instructions to set up port translation for 587 (external) to 8221 (internal), so we did and that function also worked.

I don't know why it assumes 1) that your router can re-map ports (some cannot) and 2) that your ISP blocks 8221 while allowing 587 (the only scenario that would make the re-map necessary).