Using HestiaCP 1.2.0 on Ubuntu 18.04. I’m having issue sending emails addressed to a domain configured on my HestiaCP. I’m using a Non-HestiaCP External Email server for sending and receiving emails for all my domains on HestiaCP. I’ve tested the External email server and verified that I can both send and receive emails from it - so I know its working (test was used using my gmail account).
However, I’m not able to send emails from HestiaCP to the external email server on the same local network as HestiaCP server. I tried to do a test by sending emails from the CLI and the HestiaCP host can send emails to my gmail account BUT not to any domains that is configured on my HestiaCP destine to my external server. Below are the output I get:
Failed Test
root@host:/var/log/exim4# echo “Subject: sendmail test” | sendmail -v [email protected]
LOG: MAIN
<= [email protected] U=root P=local S=368
root@host:/var/log/exim4# delivering 1jwuwu-0006JG-2L
LOG: MAIN
** [email protected]: Unrouteable address
LOG: MAIN
<= <> R=1jwuwu-0006JG-2L U=Debian-exim P=local S=1653
LOG: MAIN
Completed
delivering 1jwuwu-0006JM-54
LOG: MAIN
** [email protected]: Unrouteable address
LOG: MAIN
Frozen (delivery error message)
Successful test to my gmail account:
root@host1:/var/log/exim4# echo “Subject: sendmail test” | sendmail -v [email protected]
LOG: MAIN
<= [email protected] U=root P=local S=369
root@vhost:/var/log/exim4# delivering 1jwugV-0005uE-DL
Connecting to gmail-smtp-in.l.google.com [74.125.142.26]:25 … connected
SMTP<< 220 mx.google.com ESMTP s16si7543790pgq.76 - gsmtp
SMTP>> EHLO vhost.MY-Domain.com.com
SMTP<< 250-mx.google.com at your service, [Public-IP-Address]
250-SIZE 157286400
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8
SMTP>> STARTTLS
SMTP<< 220 2.0.0 Ready to start TLS
SMTP>> EHLO vhost.MY-Domain.com.com
SMTP<< 250-mx.google.com at your service, [Public-IP-Address]
250-SIZE 157286400
250-8BITMIME
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8
SMTP>> MAIL FROM:[email protected] SIZE=1401
SMTP>> RCPT TO:[email protected]
will write message using CHUNKING
SMTP>> BDAT 378 LAST
SMTP<< 250 2.1.0 OK s16si7543790pgq.76 - gsmtp
SMTP<< 250 2.1.5 OK s16si7543790pgq.76 - gsmtp
SMTP<< 250 2.0.0 OK s16si7543790pgq.76 - gsmtp
SMTP>> QUIT
SMTP(close)>>
LOG: MAIN
=> [email protected] R=dnslookup T=remote_smtp H=gmail-smtp-in.l.google.com [74.125.142.26] X=TLS1.2:ECDHE_ECDSA_CHACHA20_POLY1305:256 CV=yes K C=“250 2.0.0 OK s16si7543790pgq.76 - gsmtp”
LOG: MAIN
Completed
Thanks in advance for any feedback to help me solve issue.
Can you ping or trace from one server to the other?
Is it on the same subnet?
Local or public IPs?
Is this eventually VMs on the same hostnode?
Are you using a hostroute/pointopoint setup?
Hestia does not touch your network config so I am afraid you need to diagnose routing problems on your own as they can differ even based on the provider(s) network handling etc.
@falso thanks for your reply. Below are answers to your questions:
Can you ping or trace from one server to the other?
Yes, I can ping from and to both local machines (VM).
Is it on the same subnet?
Yes, I have VMs running on same physical host on same subnet. They can all ping each other and have tested connection to SMTP ports from HestiaCP vm to the email server.
Local or public IPs?
All private IP’s for VMs being natted to public ip’s.
Is this eventually VMs on the same hostnode?
Yes, VMs are all on same hostnote
Are you using a hostroute/pointopoint setup?
Well connectivity is working so I can reach all VMs from and to. Also, test layer4 smtp connection by telneting with smtp port and get connected.
Note: I know this may not be specifically a HestiaCP issue (not sure)…
I think your problem lies within the natted setup and maybe name resolution.
did you try to ping or trace the other VM by the specific domain name the mails would go to?
for the smtp test via telnet, did you use the public ip of the other machine?
remember a mail you are going to send, will not use the local ip, unless you specify these e.g. in your hosts files. so what you want to check is connectivity via their natted public IPs.
eventually the host node can already be a problem, when your packets don’t leave it because it knows the other public IP being on it itself. so your packets won’t pass through iptables/nat again to find their way to the other internal box.
you’d then need an additional rule for outgoing that target for the other public IP(s) and reroute it internally again - a shortcut so to say.
Falzo, I think you could be right that exim may need to be configured to send email from local ip. I will try the ping/telnet test using the domain names and see. Ideally, I wouldn’t want emails from the hestiacp domains to my external email server to go out the public nat ip and then having to come back same public ip. Since, all the hestia vms and my external server are all on same local subnet within the same physical host my thought it would be most optimal for the traffic to remain local.
I can also try disable iptables to see if it may be blocking anything.
BTW, can you share where I would need to configure to allow emails sent from local ip’s? Is there any reason this shouldn’t be configured for that, since, the default configuration don’t allow for it?
I think you got me wrong, it’s not about setting exim to use the local IP for sending… just think a moment about the process a regular mail leaves and arrives:
exim gets the task to send a mail.
exim figures the domain-part and looks up the ip address via a regular ns request
–> this will be the public IP pubdst of your destination VM - simply because that’s what you put in the mx record
changing anything in the exim config about sending from the local IP locsrc won’t change that. only thing you could do is providing the local IP locdst of the destination host for that target domain in /etc/hosts instead
exim will now try to connect to that public IP pubdst from 2) and for that will send out some packets…
these packets will make their way from your source vm to the hostnode where the outgoing nat rules tell them to masquerade as public IP pubsrc.
because the hostnode knows that public IP pubsrc and public IP pudst are assigned to him and probably even the same network interface, it will direct/forward the packets directly to pubdst
HOWEVER
because of this the packets do not pass again through the incoming nat rules which would clarify that packets to pubdst should go to locdst and therefore it ends up unroutable…
so the easiest approach would be to figure what nat/routing rule on the hostnode you need, to have packets coming from locsrc for pubdst redirected to locdst instead going into masquerading at all
hope this makes sense for you… I can’t remember of having that done, so I sadly can’t give you that iptables rule, that might work as intended. just want to point you into the direction I would start researching…
TL;DR; if it’s not too many domains we are talking about, I’d probably put them into the /etc/hosts files with the local IPs, so that the mail gets send directly there instead of bothering with public IPs at all
So, I was just thinking. Is there a way for me to just configure Exim to be a mail relay. If so, can I configure it to relay for specific domains? Since, my goal is NOT to use HestiaCP for my email server but I want my domains configured to use an external email server. I can configure my ext-pub-ip as the external mail server.
Ok so I’ve found a typo with the previous command I was using to send email to my external email server. So, now getting different type error message that seems to be more related to DNS issue. Below is the command being used to test sending out emails (See both failed and passed test below).
Appreciate any further help with this updated info.
*** Failed test from my hestiacp host to my external email server (Same local network)
For testing mail routing you should be looking at what your machine thinks the MX records of your domain are: dig mx My-Domain.com
That is where it will try to send it.
Also, exim has a useful command for tracing email delivery. exim -bt [email protected]
This will tell you which transports its using to send it.
Finally, for extra gnarly step by step debugging you can see what exim’s thought process is when you try to send from host 23.34.34.55 for eg. exim -bh 23.34.34.55 EHLO my.host.name MAIL FROM: [email protected] RCPT TO: [email protected]
If you type these in, exim gives you a lot of information about how its processing things.
