Can't add IPv4 address in Bindings

Problem reported by Stephen Clarke - 9/13/2021 at 3:02 PM

Submitted

I'm very familiar with SM < v15 and evaluating the new version for migration.

It is installed as a Free Edition on an Azure VM, but the public IP of the VM is not appearing as one of the IP addresses available for bindings.

It has only

::1

127.0.0.1

(local IPv4 on vnet)

(local IPv6 on vnet)

It says here: "If you need to add IPs to the list, click the New button. "

help.smartertools.com/smartermail/current/topics/systemadmin/settings/bindings/ipaddresses.aspx

But there is no such button.

Apparently these addresses are supposed to be drawn from the NIC? But it doesn't seem to be aware of the public IP, so I cannot connect to any services externally.

Advice on refreshing or manually adding to this list would be appreciated.

9 Replies

Reply to Thread

Kyle Kerst Replied

9/13/2021 at 3:39 PM

Employee Post

Hello and good afternoon. SmarterMail pulls the IP information from the Network Interface details within the Windows Registry. So, the public IP not showing in Settings>Bindings would indicate this server is in a NAT (Network Address Translation) configuration, meaning that the network behind this server is translating public IP traffic to private IP traffic. In this case you'll just want to make sure the bindings are set up on that private IP that is associated with the public address. Lastly, you'll also want to make sure you've opened the appropriate ports in both the Windows Firewall and the Azure firewall configuration areas as well. Please let me know if that helps. Have a good one!

Kyle Kerst IT Manager SmarterTools Inc. www.smartertools.com

Stephen Clarke Replied

9/13/2021 at 4:14 PM

Hi Kyle, thanks for the quick reply, really appreciate it.

Maybe I'm misunderstanding this, I was comparing the SM bindings page with our current setup where we have a standalone VPS (not in Azure).

So maybe I should back up a couple of steps.

I'm planning for the new SM server to be hosted in Azure as the first step of our migration from our existing host.

I know that Azure initially blocks outgoing port 25, I'm having a dialog with them about that, but I believe incoming port 25 should be open and I'm trying to confirm this.

Let's say the public IP is 1.2.3.4.

I believe everything in Azure is correctly connecting this to the VM.

The NSG and VM WFAS both have incoming 25 open.
From outside, I can RDP to the VM on 1.2.3.4:3389.

But I cannot telnet 1.2.3.4 25

So I moved to testing locally. Within the VM, I can successfully

telnet localhost 25

(and also via internal IP)

but I still cannot

telnet 1.2.3.4 25

This is what was making me wonder if lack of direct SM binding to this public IP was the difference.

Am I misunderstanding something here?

Kyle Kerst Replied

9/13/2021 at 4:44 PM

Employee Post

You're very welcome, happy to lend a hand! Based on your follow-up I do think this is firewall or SMTP blocking related as you're able to reach it from the server itself but not the outside, and your RDP ports are working in the same configuration. Azure does block SMTP by default and I am not aware of a way to unblock it, as Azure typically mandates the use of an Outgoing Gateway. Amazon's AWS however, will allow you to remove the SMTP port 25 block once you have your server set up to meet their requirements:

https://aws-portal.amazon.com/gp/aws/html-forms-controller/contactus/ec2-email-limit-rdns-request

Let me know what you find out there :)

Kyle Kerst IT Manager SmarterTools Inc. www.smartertools.com

Stephen Clarke Replied

9/13/2021 at 5:01 PM

Are you saying that, even WITHIN the VM

telnet 1.2.3.4 25

the request would be routed out to the public network and back again, hence affected by firewalls and blocks?

I will check with Azure to see if incoming port 25 should be open, I was sure they only block outgoing.

I'm still curious about the SM bindings page. Apparently there should be a New button where IP addresses can be added (at your help info link above). Any idea why it would be hidden in this case?

Sébastien Riccio Replied

9/13/2021 at 11:07 PM

If 1.2.3.4 is the real (internal) IP of your server attached to the interface, it won't need to go through the gateway and you should be able to telnet to the port.

If 1.2.3.4 is an external IP that is NAT'ed to your server internal IP 2.3.4.5, it will have to go through the gateway and route back.

In that case that means the ports you need to reach on your server have to be forwarded by the gateway/router/firewall doing the NAT.

In the bindings, you will never see your external IP if it's not directly attached to the interfaces. The bindings only shows available local interfaces.
You have to bind the ports on your internal IPs.

That's not specific to SM, it's how network... works, when you're using an internal IP that is mapped externally to an ... external IP.

Sébastien Riccio System & Network Admin https://swisscenter.com

Stephen Clarke Replied

9/14/2021 at 12:23 AM

Kyle, Sebastian, thanks. Really appreciate the support.

So it looks an Azure restriction after all. But I thought they still left incoming 25 open by default.

I will follow up with them and let you know how I get on.

Kyle Kerst Replied

9/14/2021 at 4:07 PM

Employee Post

You're very welcome, happy to lend a hand! In my experience Azure doesn't allow any outbound SMTP on port 25, and you would need to implement an outgoing gateway to route the email out of the server successfully. I hope this has been helpful. Have a good one!

Kyle Kerst IT Manager SmarterTools Inc. www.smartertools.com

Tom De Busscher Replied

1/10/2022 at 2:48 AM

Hello Kyle,

My problem is close to this. I also have an Azure VM with Smartermail running on it. SM detects in the bindings only the private IP address of the VM 10.1.0.4 and not the public IP address. This seems normal behavior, according to your post and also a Microsoft post that says "Azure VM itself is not aware of its own public IP. The mapping of public IP and the private IP is done by the platform."

The sending out mail works fine with me, no firewall issues. The problem I'm having is that in the SM logs it says that many mails aren't being delivered with reason 550 5.7.1 Command rejected.

In those SM logs, I see that SM is now sending from the private IP address and not from the public IP address. In this case it's logic that the mails end up in spam, because of the 10.1.0.4 address.

What can I do to solve this problem?

With kind regards,

Tom De Busscher

Kyle Kerst Replied

1/10/2022 at 11:00 AM

Employee Post

Hello Tom! I believe this might indicate a couple of possible issues. While the private IP will show in the logs, it should show up on the remote end as a public IP address assuming the network side of Azure is set up properly. Do you have SPF/RDNS/etc set up for that server and domain already? The command rejected might be due to an SPF failure or something similar instead. If you can submit a support ticket on this we would be happy to help get to the bottom of it for you. Have a good one!

Kyle Kerst IT Manager SmarterTools Inc. www.smartertools.com

Back to Community Threads

Please leave this box unchecked

Reply to Thread

Enter the verification text