1

Topic: Unable to connect from remote

Hello,
your app works beautifully while connected to the LAN / WiFi.
However I can not connect for the life of me remotely.

I put a server in a DMZ to play with it, port 4444 is open, is there a trick to get it to work?
Do I need to use a different Bridge Service URL ?

No matter what I tried I just get "Error. The connection timed out."

Any input / help / idea / suggestion is appreciated.

2

Re: Unable to connect from remote

Hello,
Instead of putting server to DMZ, you can try configure port forwarding. It's more secure and flexible. Does your ISP provide public IP and allow incoming connections? When you are testing remote access, you should disable WiFi on your iOS device and connect to public IP only from WAN interface to be sure.
And the last thing, on your router try to forward from WAN:443 -> server.local:4444 maybe your mobile carrier block exotic ports like 4444.
You can test port reachability at http://ping.eu/port-chk

3

Re: Unable to connect from remote

Hello,

I put it back in the LAN, and did portforward (WANIP:443 -> LANIP:4444). No dice.
My ISP is dynamic, with a public IP, I was able to setup RDP access just fine(WANIP:3389), I don't see why this would not work.

That's how I test:
Wifi on -> Internal IP -> Works fine
LTE (wifi off) -> External IP:443 -> No dice. (timed out)

Let me ask you this, when connecting remotely what should I give the app?
Host/IP: LANIP
Bridge Service URL: https://WANIP:443

Thanks for the help.

4

Re: Unable to connect from remote

Host/IP leave the same as when you are connecting from LAN or better 127.0.0.1 if WinRM bridge is on the same server you want to manage. Bridge url seems valid there must be some firewall involved. Do you have installed any antivirus or something that block incoming connection from the outside? Do you have multiple network adapters?

5

Re: Unable to connect from remote

From following this scenario I'm wondering what a packet capture might show?  alexw, I'm assuming that you're able to telnet to it successfully in both the DMZ scenario and the port forwarding scenario?  If yes on the forwarding scenario I think it's a matter of looking at the possibility of additional ports being used on the return path that may be getting blocked from getting out? 

A packet capture would have to be run internally first to see a successful connection, then another one run using DMZ and or Port Forwarding to see where the primary difference is.  I may be a bit off, as Networking is not my specialty, but I think it might help?