Firewall in MTA mode not sending out mails

Hi Sven,

Thank you for reaching out to Sophos Community.

Have you tried to use any how-to videos, documentation, Sophos Assistant, or KBA to try to check the issue?

Can I inquire what firmware version you’re using?

The firewall rule is created automatically to allow SMTP/SMTPS traffic, which is vital for handling email communications for incoming and outgoing traffic.

• Configure the SMTP and TLS settings.

Upon Simulation, Switching back to Legacy mode and then to MTA will restore the MTA SMTP default rule.

For additional reference to the Rule. I've attached it below 

FW Rule

NAT Rule

• Sophos Firewall: MTA troubleshooting guide

Hello,

there is no documentation, that this SMTP rules is essential for SMTP proxy MTA traffic and must stay in the fireall rule list with its id#, because it is hidden linked to the MTA  Proxy. This hidden link is not obvious.

Admin has to  secure this rule and limit it to its needs.

When you delete rule MTA proxy seems to act as transparent proxy, when there is a rule allowing SMTP outgoing for a device. The mails are intercepted by MTA proxy and then could not be send, because linked firewall rules is missing.

When addinf the linked firewall rule again and link it with the mta firewall id script it is working again.

I think this rule should be marked as special rule and is not deletable.

Sven

Hello Sven,

I do not agree with you. There is a description in both the firewall rule and the linked NAT rule.

The Firewall rule description says: "This rule was added automatically by SFOS MTA. However you could edit this policy based on network requirement."

In the linked NAT rule the description tells you: This rule was added automatically by SFOS MTA.

I am glad, that these rules are not "hidden" in any way, rather they are adjustable to special needs.

Helo Phillipp,

yes but it is changeable, and the information is gone. Documentation is not saying anything about the behaivour and linking to mta.

When deleting rule, which is said not problem here in the forum, it is getting worse.

The Rule should  have an explicited link to Mail proxy shown, must be not deleteable.

Sven

I agree, had a similar issue with it.

Not agree:

Why deleting rules, when you (obviously) not know what that rule is for or what it does? 

Sorry, but now it's the fault of Sophos or the forum community?! Be happy you have been helped here and don't blame other!

Not agree:

Why deleting rules, when you (obviously) not know what that rule is for or what it does? 

Sorry, but now it's the fault of Sophos or the forum community?! Be happy you have been helped here and don't blame other!

Quallensaft What do you want to say? The major Problem is an autoadded rule, opening the firewall for smtp.

I just like to see some more documentaion about the this rule, as it seems to be sticked hidden to the MTA Proxy.

Now I no it, but others might need the information, too.

Just stick with the rule, as first rule for smtp and change it to a secure one directly after setting up mail proxy.

Sven

Believe or not: there is no hídden "LINK" as you repeat here for many posts now. This rule is added when setting up MTA mode, it is clear to see, what it does: it opens ports for the MTA-services. That's what a firewall rule is for. There is no other magic behind it.

Why should a daemon ON the firewall use other rules than firewall and/or NAT rules?

You overcomplicate things here!

Let me clarify something here. 

The MTA Service in fact utilize the MTA Rule and use it to allow "itself". Which means, if the rule is deleted, the MTA Service gets blocked from the firewall. The reasoning is: To prevent Spoofing, faulty MTAs and Blacklisting of customers, Sophos made the call to say: If you enable a Rule, the rule indicates that the firewall can and will use SMTP Port 25 communication. If you delete the rule, it will stop to communicate* on port 25. 

The firewall rule is "allowing and NATing" the SMTP Traffic. 

As stated in the firewall rule: 

It will act as an transparent MTA as well. But you could restrict that from happening by changing the zones or removing it. 

What you can do: In fact you can disable this rule, which still attaches the NAT to the MTA. This means the firewall knows the NAT and allows the traffic and you dont get blacklisted. 

So long story short: The MTA is the only service on the firewall, which needs a FW + NAT Rule to work but it will be auto generated per default. This is simply to protect the admin from doing a wrong configuration in the first place. 

*(After a reboot). 

Thanks for clarifying this.

LuCar Toni

This seems not to be correct. Because you wrote in other forum post, it is save to delete the auto added rule, because it is not needed.

When using proxy in MTA Mode, the rule is not need, I have several setups like this. Because MTA mode accepts traffic cause of policies and relay hosts config. With this config mail flow is working.

Problem is when having a rule alowing smtp to WAN, without smtps scanning enabled, this mails are intercepted by MTA Proxy and then can not be delivierd cause of  using the new rule, which is not working.

What do you mean with reboot, I have a customer running without autoadded rule, just MTA Proxy and internal exchange allowed to relay. And even after rebbot/firmware update everything is fine.

Hello Sven,

can you give the source of your citation, please?

Hello Philipp,

what do you mean? I like to discuss the MTA proxy configuration. I am dealing with Astaro/Sophos SG for 20 years. The MTA proxy setup on XGS is a little bit picky, cause not all things are obvious.

Sven

Hello Sven,

you mentioned a post from LucarToni in another form thread. We don't know about this info without a link to that source.

 MTA mode and Autofirewall rule in v18 

 MTA mode and Autofirewall rule in v18 

Actually you are correct. This rule is not needed for a MTA Setup. 

It will open a Transparent MTA Proxy, so scanning all Mails going through XG port 25. 

There for the explanation of this rule is: Please adjust this to your Firewall setup. 

It is a simple helper to get "every setup running" in the first place. 

There was a use case of this rule in V17 to chose the outgoing WAN interface / alias in case of multiple addresses. 

This is gone for V18, because now you can select a SD-WAN PBR or a NAT rule. 

XG will work perfectly fine as a MTA "Proxy", if you delete this rule and activate the MTA in Device access.

So your Server and WAN Servers can communicate with the XG Interface Port 25 to deliver mails. 

My post is a V18 EAP Post, this behavioral could have changed in this 4 years of development. 
If you want to have more documentation or changed documentation, you can raise a change here: 

 Discussions