2

I have a Postfix mail server, running on a host with multiple network adapters, one of which is a virtual tun0 device. I need this mail server to accept connections on any adapter - and send email only on the virtual tun device.

I have a configuration, in line with the answer to this question, which defines smtp_bind_address=10.20.30.40 - where 10.20.30.40 is the address associated with the tun0 device. This server server doesn't support IPV6.

For years, this appeared to work perfectly - until, one day, the tun0 device died - and Postfix sent email over the default network device, eth0 (10.0.0,1) not tun0.

Is this expected behaviour? Are there settings I can change to ensure that Postfix only ever dispatches email over tun0 (10.20.30.40) - leaving messages in the queue if tun0 is not available?

In case it is relevant, this is on Ubuntu 16.04.2 LTS with Postfix version 3.1.0-3. tun0 is implemented using OpenVPN version 2.3.10-1ubuntu2.1

-- Edit to add extra details --

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.0.1        0.0.0.0         UG    0      0        0 eth0
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.20.30.40     0.0.0.0         255.255.255.255 UH    0      0        0 tun0

This server runs several services - of which Postfix is only one. Only email needs to be routed over 10.20.30.40 - all the other services need to be routed over the default gateway.

aSteve
  • 231
  • 1
  • 4
  • 10
  • Expected. Could have broken at any time. What is the output of `route -n`? – hookenz Jul 11 '17 at 20:43
  • I realise, now, that it could have broken at any time. This is why I'm asking - what's the minimum change I can make to make the configuration reliable? [See 'extra details' for route -n' output.] – aSteve Jul 11 '17 at 21:16
  • How does postfix send it's email, does it use a smart host available only via the tun interface or is it sending direct? It sounds like the later to me. – hookenz Jul 11 '17 at 21:20
  • I suspect the latter as I don't know what a 'smart host' is. I just have an OpenVPN tunnel that exposes a public IPV4 address to the server running Postfix on the tun0 device. – aSteve Jul 11 '17 at 21:21
  • Only email need be routed via tun0. Only tun0 has a static IP address, with a correct RDNS, for my exclusive use... it has relatively low bandwidth. In contrast to tun0, eth0 will route traffic to the most available (cheap) network connection. Its public IP address may change at any time - I can, but I do not want to accept TCP connections on it. – aSteve Jul 11 '17 at 21:29

3 Answers3

1

What happens is that postfix will use the configured smtp_bind_address first. In your case it's a static ip bound to tun0. It will pass out via tun0 when it's up. If tun0 is down then the client bind will fail causing postfix to fall back to the default behavior of not binding the client tcp endpoint and it will therefore will use the default route which is connected to eth0.

It would seem that postfix does not provide a suitable override for smtp_bind_address failure.

So the answer is to simply block outbound email on port 25 on interface eth0 using an IP tables rule. This will cause all email to queue up for a time before failing or until tun0 comes back.

Something like the following should work:

iptables -A OUTPUT -i eth0 -p tcp --dport 25 -j DROP

That will prevent all email being sent out port 25 via eth0 and originating directly from your server (not routed). It will not block email traffic being sent via tun0.

hookenz
  • 14,132
  • 22
  • 86
  • 142
  • This makes sense... though I didn't expect that I'd have to use iptables... a solution that is complicated because I also use shorewall. I can delve into my firewall configuration - I'd previously assumed that resorting to a firewall, for this, was something that just 'covered-up' something else that was wrongly configured. – aSteve Jul 11 '17 at 22:25
  • The complication is that your tunnel endpoint combined with a dynamic ip. As I said before, most ISP's will allow you to relay your email. There are some paid offerings as well that are inexpensive. e.g. <$10 a month. You could also ask for a static IP on your DSL line. Some ISP's can offer that too. Then you wouldn't need tun0. Or is the tun0 option because they couldn't offer you a static IP? – hookenz Jul 11 '17 at 22:34
  • The tun0 approach, to bring a static IP address to me, however I connect to the Internet, arose from frustration at very limited ISP offerings at my location. I want to use this IP, consistently, both to send and receive email - without having to rely upon the mail servers of whatever ISP I use to establish my net connection. With the exception of the frustration in configuring Postfix to only send on the named interface, the tun0 solution is a perfect fit for my needs and constraints. – aSteve Jul 12 '17 at 07:08
  • Sure, I've had to do something similar to get extra IP's down to a LAN. Sometimes we need to get creative. Did the iptables approach solve it? – hookenz Jul 12 '17 at 19:49
  • Not yet, but I am certain that it will behave as we expect. Implementation using IPTables, for me, on this host, in practise, involves jumping through a few hoops... and I've not got around to it yet. Of course, I also hope that we're wrong, and that firewalls are not the only solution. It would be optimum if processes other than Postfix could still make outgoing connections to port 25 from the same host. – aSteve Jul 13 '17 at 18:55
  • @aSteve - Do you have access to the local shell of the shorewall? try this: sysctl -w net.ipv4.ip_nonlocal_bind=1. It allows non-local bind. i.e. bind to address that isn't yet up! might also work. – hookenz Jul 13 '17 at 21:30
0

From what I could gather and test in a lab, this appears to be working as intended. smtp_bind_address will failover to another inet_interface if not available.

Maybe you could setup another Postfix instance that only has a single inet_interface of 10.20.30.40, and postmap/relay outgoing to that? Perhaps then you could receive via your multiple adapters, and force sending out over a single IP.

Ulfy
  • 351
  • 1
  • 5
  • Many thanks for your efforts to confirm this behaviour. Two instances of Postfix - only to ensure that my email is dispatched *exclusively* from the IP address corroborated by my SPF record - sounds, to me, like a design fault - if this is "by design". – aSteve Jul 11 '17 at 20:16
  • Since the desire is driven by SPF compliance, could you just add your other inet_interface IPs to your SPF record? Individual ipv4 entries don't count against the DNS lookup limit of SPF. – Ulfy Jul 11 '17 at 20:27
  • Unfortunately not... I can only trust the IP address of the correct device. The 'default' device is connected to an appliance that directs traffic through a dynamic IP address that is allocated by my ISP. Not only do I want my SPF record to match, but I also want my SPF record to only detail only the IP address for which I have exclusive use. Among other problems, my ISP's dynamic IP addresses are on 'dynamic IP' blacklists. Email should only emanate from my static IP address, which is exposed to my Postfix server using OpenSSL. – aSteve Jul 11 '17 at 21:08
0

It's been a while since I had to mess around with postfix. But I think you should be using a smart host relay.

A smart host is a type of email message transfer agent that allows a Simple Mail Transfer Protocol (SMTP) server to route email to an intermediate mailserver rather than directly to the recipient's server.

The relay would be the mail server that corresponds to a sender SPF record in your mail domain. Your ISP should be able to act as a smarthost email relay for you.

From memory it could be as simple as setting a setting in /etc/postfix/main.cf

e.g. relayhost = mx1.mydomain.com:587

Then you wouldn't need to care which interface mail is sent from.

hookenz
  • 14,132
  • 22
  • 86
  • 142
  • Thanks for the definition... I agree, a "smart host" would work - but... it would require that I host an SMTP server instance in the cloud - not just an OpenVPN end-point. For me, a smart-host is a very inconvenient solution as it would require that I rent a new, specific, cloud-hosted provision. I'd like to avoid this. – aSteve Jul 11 '17 at 22:16
  • @aSteve - see my other answer. It should solve it for you. – hookenz Jul 11 '17 at 22:17
  • Many internet service providers can act as smart host relays for your domain. I've used that before and they haven't charged me. Maybe they would now. – hookenz Jul 11 '17 at 22:20