This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How to publish two mail servers each with it's own public IP

Hi,

We need to publish a new mail server for a new domain, but we want to publish it with it's own public ip.

The story :)

We have Sophos UTM to manage mail protection for our principal domain, let say example.com

The public ip for the UTM is 192.168.1.1, it's internal one is 10.10.10.1.

The public ip for our mail server is 192.168.1.2, it's internal one is 10.10.10.2

In the present we're using an SNAT to modify the source IP of all outgoing smtp packets from 192.168.1.1 to 192.168.1.2 to match the MX and PTR declaration of our mail server on the internet.

 

Now we have to manage a new domain, let say foo.com, and we want to use another public ip address to publish the mail server of this domain, for example 192.168.1.3, and the corresponding internal one is 10.10.10.3

For incoming emails, SMTP profiles does the trick, if the domain is example.com deliver internally to 10.10.10.2 (mail.example.com), if the domain is foo.com deliver internally to 10.10.10.3 (mail.foo.com).

Our problem is with external delivery, how to modify the source public ip from 192.168.1.1 to 192.168.1.2 if the sender is 10.10.10.2 (example.com) and modify the source ip from 192.168.1.1 to 192.168.1.3 if the sender is 10.10.10.3 (foo.com)

I hope this is clear, if you need more details let me know.

Regards.



This thread was automatically locked due to age.
Parents
  • Oledada is right.   I will elaborate a little on the options.

    Transparent mode may be the easiest solution.  You use NAT rules to map the internal addresses of the mail servers to the external IPs that will be used for send and receive.   You publish an MX record for each domain on its dedicated address and that is the only address that will be used for either incoming or outgoing mail.   Transparent Mode is a global setting, so your existing domain will need to switch from Standard to Transparent at the same time.

    Your defenses need to change when you switch between Standard SMTP and Transparent SMTP.   To prevent unauthorized (infected) internal machines from sending outbound mail:

    • With Standard SMTP, all you need is a firewall rule like this: 
      FROM <any IP> <any port> TO <any server> <port 25> ACTION <block>.   
      Traffic that is addresses to the UTM will be handled by the SMTP filter, traffic not addresses to UTM will be blocked by this firewall rule.

    • With Transparent SMTP, you need two rules, in order of precedenc:
      FROM <any IP> <any port> TO <MAIL SERVERS> <port 25> ACTION <allow>
      FROM <any IP> <any port> TO <any IP> <port 25> ACTION <block>    

    Transparent SMTP assumes that UTM is your firewall, or is on the network flow path between your mail servers and your firewall.

    In transparent mode, UTM will not log a RECEIVED-FROM header in the message headers.

    If you stick with Standard Mode:

    • Outbound messages from both domains will use the primary IP of the exiting interface.   I do not see any way to override this behavior, because the packet is now originating from the UTM and not from the mail server, so SNAT rules do not apply.
    • By default, inbound messages for either mail domain will be accepted on any Public IP of the UTM.  You can limit this by using DNAT-to-DeadEnd rules for the Public IPs that should never accept port 25 traffic.   For the incoming addresses that are not blocked, you will not be able to require a specific mail domain to arrive on a specific IP address.   However incoming target address does not really matter - the SMTP filter will handle the traffic in the same way regardless of the Target IP used, senders are not likely to use an address that is not published with MX, and there is no advantage to them if they do.
  • Douglas no need for firewall rules when transparent mode is active. And the header log will be shown. Maybe you have to wait 5 minutes from the swich betwen them

Reply Children
No Data