Sophos Firewall blocking outgoing IPv6 SMTP traffic

Hi,

you don't need a NAT if you have real IPv6 allocations for internal addresses. Do you have an IPv6 rule allowing port 25 out?

Ian

Hi,

Yes, I have an IPv6 rule allowing port 25 out (as show in previous screenshot).

NAT is used to choose the right IPv6 address (for SPF) for outgoing SMTP traffic.

But, we don't use (yet) internal IPv6 addressing.

Nicolas

Hi,

the XG treats IP4 and IPv6 as seperate networks.The XG does not translate IP4 to IPv6.

You have IPv6 addressing on your mail server according to your NAT rule but no firewall rule and the traffic is just hitting a blank wall.

Your firewall rule is an open relay.

Ian

Hi,

I understand that XG treats IPv4 and IPv6 as separate networks in firewall rules, but it shouldn't in a proxy? If my mail server use the firewall as a relay in IPv6, the firewall'll try to deliver every email in IPv6, it could not work?

In the packet capture, I can see that the IPv4 traffic from the relay in treated as "Generated" (by the mail proxy), why is the IPv6 traffic not treated the same?

What is really strange is that I got it running once last year from a telnet running on the mail server : 

2023-12-13 08:09:55.959Z [55528] FZVq1i-KAbKN0-P3 ** nicolas.xxxxxxx@gmail.com F=<nicolas.xxxxxxxx@example.com> P=<nicolas.xxxxxxxx@example.com> R=default_mx_router T=remote_smtp H=gmail-smtp-in.l.google.com [2a00:1450:400c:c00::1a]:25 I=[xxxx:
xxxx:c2d::1]:46476 X=TLS1.3:TLS_AES_256_GCM_SHA384:256 CV=yes DN="/CN=mx.google.com": SMTP error from remote mail server after end of data: 550-5.7.1 [xxxx:xxxx:c2d::1] Gmail has detected that this message is not RFC\n550-5.7.1 5322 com
pliant:\n550-5.7.1 'From' header is missing.\n550-5.7.1 To reduce the amount of spam sent to Gmail, this message has been\n550-5.7.1 blocked. For more information, go to\n550-5.7.1  https://support.google.com/mail/?p=RfcMessageNonCompli
ant and review\n550 5.7.1 RFC 5322 specifications. j14-20020a5d448e000000b00333295f188csi6080086wrq.934 - gsmtp DT=0.618s

Regards,

Nicolas

You need seperate rules for ip4 and IPv6.

ian

Yes, but my mail server is IPv4 only and IPv6 rules are not used (usage = 0)...

Then why are you trying to use IPv6 addressing?
ian

I'm trying to migrate a SMTP proxy running on UTM in IPv4 and IPv6 to an XG firewall. It seems that XG is not a real SMTP proxy, but some sort of interception server?

I'm trying to migrate a SMTP proxy running on UTM in IPv4 and IPv6 to an XG firewall. It seems that XG is not a real SMTP proxy, but some sort of interception server?

Hi,

I did some more testing with the SMTP relay of Sophos XG.

If you enable MTA mode on email settings and allow access to some zones from device access, you have configured a SMTP relay. Your firewall is listening on port 25 and accept emails from your network. However, it is unable to send them on Internet, even if you allow host based relaying. Every try to send an email finish with a timeout in the relay. The generated traffic from the relay is blocked by the internal firewall.

You need to configure a rule to allow traffic from your internal zone to Internet and select "Scan SMTP" : without this rule, nothing is working as expected.

When you have this rule (automatically generated when you switch MTA mode to on), you can send emails using Sophos XG as a relay. However, the relay is unable to send IPv6 traffic as the rule is IPv4 only. When you send an email to Gmail, Sophos receives it, check the MX of Gmail, find the DNS gmail-smtp-in.l.google.com ant try to connect to port 25 of 2a00:1450:400c:c1b::1a, which result in a timeout : 

2024-02-06 19:05:16.438Z [30098] lN2ijY-sYARXZ-t9 H=gmail-smtp-in.l.google.com [2a00:1450:400c:c1b::1a]:25 Connection timed out

If you configure a rule to allow traffic from your internal zone to Internet in IPv6, it isn't used as your email server is sending over IPv4!

If I understand the design of the SMTP relay correctly, you can use it only in IPv4 OR IPv6, not both. If you connect to it in IPv4, you can send emails over IPv4 to Internet, if you connect to it over IPv6, you can send emails over IPv6 only on Internet. I can't understand why you need a rule to allow a SMTP relay to send emails over Internet, it should be an automatic allowed rule...

For the incoming part of the relay, it works both in IPv4 and IPv6 if you create the right rule for each protocol.

Regards,

Nicolas

Hi,

Today, I finally found the reason of all this mess.

If you read carefully the log of the smtp daemon, you can see when it receives an email that it tries to match a firewall rule : 

S='xxxxxxxx@example.com' R='xxxxx.yyyyyygmail.com' Subject='Test Gmail' Size='1816' Status='Mail has been queued for delivery.' src_ip='xxx.xxx.xxx.xxx' src_port=46148 user_id=0 user_grp_id=0 fw_id=0 src_zone_id=10

If it match a rule (fw_id != 0), you'll be stuck in this rule and the firewall will not be able to send a IPv6 email.

However, it it doesn't match a rule (fw_id=0), some magic happens and it will be able to deliver both IPv4 and IPv6 emails on Internet!

I just had to delete my rule allowing SMTP from my email server AND add an exception to my dropping and logging rule to prevent SMTP to be intercepted.

I hope it could help someone to understand this strange behavior.

Regards,

Nicolas

Hi,

Just to be complete, if you follow this way, you won't be able to SNAT your SMTP trafic... You're in firewall rule id 0 and there isn't any (s)NAT applying to it.

However, you can SNAT all your system-generated trafic with this console command : 

set advanced-firewall sys-traffic-nat delete destination 0.0.0.0 netmask 0.0.0.0 interface wan snatip xxx.xxx.xxx.xxx

For IPv6, as nothing is working by default, I just put my SMTP IPv6 address as main address on my wan interface.

Anyway, everything is working as expected, as any IPv4/IPv6 SMTP relay!

Cheers,

Nicolas

Hi,

I discovered today that I had to disable also incoming emails rules in firewall : recipient verification with callout wasn't working properly (timeout).

Now, I'm running a real SMTP relay without any firewall rule and everything is working perfectly!

Cheers,

Nicolas