Here is a situation we observe.
Our ISP ask we use their DNS servers (those provided by the link) to request the name of their smtp servers. If we don’t, we get another address making our ISP think we are not on their network, requesting for a password.
It looks like having such an ISP on WAN 2 is at least a trouble. This has been confirmed with your support team.
Would it be possible in the future to have a firmware that resolve the smtp server name provided in “SMTP forwarding service” using the DNS information given by the associated link?
Thank you and best regards
Ummm one clarification if I may - we want to have Peplink resolve certain hostname (e.g. your SMTP server name) to certain WAN link, and when it goes down, use other links as appropriate, yes?
Well I’m going to try to explain it better.
=== About one of my ISPs ===
Assuming my ISP smtp server name is : smtp.myisp.com
If anybody in the world try to resolv smtp.myisp.com, it gets 1.1.1.1. Using this address leads you to an smtp server that require an authentication.
If you use the link of your ISP and you request the DNS servers the link provide, it gets 2.2.2.2. Using this address with the associated link leads you to an smtp server that doesn’t require authentication.
=== Regarding SMTP Forwarding feature ===
The configuration is (assuming myisp1 and myisp2 have no relationship) :
ISP 1 : Enable Box checked - Server: smtp.myisp1.com - SMTP port 25
ISP 2 : Enable Box checked - Server: smtp.myisp2.com - SMTP port 25
Assuming DNS forwarding is off, here is my understanding of the way it works:
1 - Client A send an SMTP request to whatever SMTP server
2 - Peplink box intercepts it
3 - Peplink box decides to use ISP1 or ISP2 according to “Outbound Policy” rules
4 - Peplink resolves SMTP server address using the information given in the “SMTP forwarding feature”
5 - Peplink connect client A to the address resolved in 4 using the associate WAN connexion (stage 3)
The trouble for me is at stage 4. If the peplink doesn’t request the DNS servers associated with the ISP that has been choosen at stage 3 and using this link choosen at stage 3, it will connect client A to 1.1.1.1 instead of 2.2.2.2. And unfortunately it’s what it does.
If I configure smtp forwarding feature this way (assuming the ISP that is applying this policy is ISP2):
ISP 1 : Enable Box checked - Server: smtp.myisp1.com - SMTP port 25
ISP 2 : Enable Box checked - Server: 2.2.2.2 - SMTP port 25
This configuration works, but I lose all the infrastructure my ISP has installed to be sure I will get good addresses using smtp.myisp2.com (load balancing, server shutdown…).
Are those information helpful?
Did it helps ?
Just to add, regarding what Kurt proposed. If I can force the box to always resolve certain hostname like smtp.myisp2.com on a specified link however it is used hereafter, it should also solved the problem. Maybe a little bit more harder to configure but as efficient.
Maybe you could make entries in your host file on the pc’s? That way they never need a DNS lookup. Or change the smtp qualified domain name in your email clients, to one that you can control. i.e. smtp-wan1.e-gaulue.net and then specify the IP of the ISP’s inside mail server access, as needed.
Ummm iif a local static DNS entry works, then we can define it on Balance built-in DNS proxy too. This way, we don’t need to modify the host file on each LAN client, but maintain a single DNS record on the Balance built-in DNS proxy - much neater this way.
It is under Network > LAN > DNS Proxy Settings > Local DNS Records
Well Kurt and rosh_pl, I’m not sure I understand your solution. The SMTP forwarding feature is done to balance SMTP traffic between ISPs. As long as the balance didn’t choose which one to use, client or server have no idea with who there are going to be connected with despite the smtp DNS name they have got. The balance is the only one that got this information and that can properly link users to servers using kind of DNAT/SNAT. So the balance must resolve the smtp name to accomplish this. According to me, this SMTP forwarding feature is a great idea.
I’ve looked deeper at Kurt proposal using the internal DNS proxy. But, as you can just set one record associated to one name, this idea is exactly the same as hard writing IP address in the “SMTP forwarding feature”. It won’t add kind of load balancing feature. Dnsmasq is a good tool that could handle it but I’m not sure that the embedded solution.
If there is a way to change balance configuration through command line I could write a script from a machine associate with the link and that just do nslookup smtp.myisp2.com dns1.myisp2.com. Then use the results to automatically change the balance settings information every 1 to 2 minutes. It won’t be clean, but at least it would be better than no security at all in case of ISP changes or server shutdown.
Or, another idea: is there a way to know and fix the DNS server the balance is using for itself?
What are they?
- The first it gets depending on WAN connexion time
- The 1st of the first link, then those of the 2nd link,…
- Public DNS
…
AHHH… how about using a couple of outbound policies to prioritise DNS lookup traffic by domain name to their respective ISP.
This works, yes?
It looked to me as a really good idea (even if what you propose doesn’t do what you expect). To sum it up, I would say: If DNS can’t properly deal with it maybe we can mislead the balance at the routing level. But unfortunately, it’s not possible with the tools we have.
The rule you propose is transformed to kind of “ip rule” commands. I would translate it this way: if I have a packet from any inside LAN IP to the machine called smtp.myisp.com on port 53 then go out using rather this WAN. This will not resolve my trouble. First, because smtp.myisp.com is not a DNS server but an SMTP one. Secondly, even if I could force the balance to use only one WAN connection for DNS queries, this won’t be enough if the DNS server chosen for the resolution by the balance is the one of the other connection. So we also need to add a DNAT to request the right connection DNS server. There is nothing to do that trough the GUI.
Your idea has made me think a little bit more on the problem. According to me all is done through kind of iproute. Official iptables can’t DNAT in POSTROUTING table has it would be needed by the SMTP forwarding feature. Moreover, all those command iptables and iproute can’t work with FQDN as smtp.myisp1.com. This means there is a DNS resolution at the time the rule is set and not every time it is called. The only solution to have fresh DNS information is to reset/reconfigure the rule regularly. But, this thought also convinced me Peplink could solve the trouble really easily if they wanted to.
Ummm this is a matter of updating the DNS cache that SMTP forwarding uses over time.
Your understanding of the SMTP forwarding behaviour is correct. For SMTP forwarding, Peplink resolves the SMTP server hostnames and caches their IP addresses. And yes down the road the ideal solution is to have Peplink update the cache regularly.
For now we will have to stick to using your SMTP server IP addresses for SMTP forwarding. This will make sure your SMTP traffic stays with their respective ISP but this limits load balancing on your SMTP traffic. Load balancing will still help with your other traffic.
