1

I am trying to set up FileMaker Server on a new Azure Windows 2012 VM (not classic).

The step that has me flummoxed is opening the ports. I have created the inbound end points for the three required ports in the Azure console and created the 3 inbound rules in the windows firewall.

Two of the ports, 180 and 1443 seem to be open, verified with an online port tester. However 16001, which is the most important one to get started is not open. I double and triple checked everything and the three rules are identical except for the port number.

For the heck of it (and because I thought maybe there was a problem with higher numbered ports? - grasping at straws here) I randomly tried opening port 181. Did not work.

I can connect to FileMaker Server using port 16001 locally so I at least know it's operational. But, I can't make any external connections to the FileMaker Server.

Edit:

Learned a new trick and ran a NetStat on my server for each port. Here is a screenshot.

NetStat OF Each Port

The two that are working, 180 and 1443 are using 0.0.0.0 and the two that aren't working are using 127.0.0.1 and 10.0.0.4. I partially understand the difference between 0.0.0.0 and 127.0.0.1 in this context and explains why 16001 is not working. But where did 10.0.0.4 come from?

And how do I change everything to use 0.0.0.0? Apparently not in Windows Firewall where the configurations are identical.

Brad Mathews
  • 163
  • 2
  • 8
  • To confirm - You are aware that you need to open these ports both by creating an endpoint within the Azure portal AND by creating an inbound rule in the server's Windows Firewall? – Taz Mar 23 '16 at 04:55
  • @Taz it sounds like he is using Azure Resource Manager VM's (V2 not classic) in which case the concept of end points has gone away. Instead he will need to make sure that the port is configured in the appropriate network security group, as well as the Windows firewall. – Sam Cogan Mar 23 '16 at 14:21
  • Yes, I used the network security group settings to add the Inbound security rule to my VM and I added inbound firewall rules to the firewall on my VM. It worked on 2 out of the 4 ports I tried, and as far as I can tell I did everything identically. I checked things this morning with a different port scanner, Pentest-tools.com. It does not see 1443 but yougetsignal.com does still see it. wtf? I disabled the firewall rule on the two working ports and they went dark. I re-enabled the firewall rules and then removed the inbound security rules in the security group and they went dark again. – Brad Mathews Mar 23 '16 at 16:30
  • Hi. As you've identified, the application is listening only on loopback (127.0.0.1) so it can't be reachable outside the VM - you need to troubleshoot the application (contact the vendor). The other services are listening on "all available interfaces" represented by "0.0.0.0". Once a connection is established, it has to have a valid IP address both in source and destination. That's why you see 10.0.0.4 on established connections - that's your VMs DIP. – Pedro Perez Mar 29 '16 at 13:42

1 Answers1

0

You can verify your Windows firewall rules by trying to connect to the server from another VM on the same Vnet.

Pascal Sauliere
  • 69
  • 3
  • I spun up another VM and confirmed that the two ports that are failing from the external connection are also failing from within the Vnet and the ones that work are still working. See edit to my original post for some more data I dug up. – Brad Mathews Mar 23 '16 at 20:08