Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I have completed setting up qmail on my LAN, and have the firewall properly forwarding SMTP and POP to it, but I am not sure how to configure roaming users.
Details: on the LAN, the email box is 192.168.1.3. I added an entry in their HOSTs file which says
192.168.1.3 mail.companyname.com
BUT, what do I do when a laptop user leaves the company, and wants to POP their email from home? Yes, they are window$ users. I thought that HOSTS under windows would fail at home (since 192.168.1.3 doesn't exist) and then would hit their DNS server to resolve mail.companyname.com. But, I was wrong.
So, I have looked into setting up a DNS server on our firewall so that on the LAN, it would resolve mail.companyname.com to 192.168.1.3, and in the outside world, everything would work fine since the MX records are properly set.
Is this the right approach? Or is there an easier way?
(I apologize for posting this question here... couldn't really find adequate search terms for google)
If you set up DNS to point to the outside IP then it sould work no matter where the request originates, as long as the proper ports are forwarded.
If the request happens from outside the protected network then that is pretty straightforward. However, if the request originates from within the network then the router/firewall ICMP will redirect the client to the internal server because the router is "smart" enough to know.
I see the problem in non-routeable 192.168.x.x address. You can use this address class only inside LAN.
But if qmail is working correctly and it can accept mails from "the world" it means it works with public IP. Am I right? If so you should bind the public IP with ' mail.companyname.com' and using iptables build the possibility of using this address from inside and outside the LAN as well.
mail.company.com points to the external IP of the firewall.
inside the network, if you point your mail client to mail.company.com, it resolves to the external IP of the firewall, then errors out, since the request is originating from the LAN. The IP of the firewall internally is 192.168.1.1.
The firewall is running RedHat Linux -- perhaps I need to configure the firewall rules to say "All requests from internal going to remote firewall IP, redirect to internet firewall IP" Or something like that.
You need to forward the the SMTP and POP ports from the external IP to the internal server's IP. When you make a request from inside the LAN, the DNS server will resolve to the external IP. Next, your client will attempt to make a TCP connection to the external IP, but the firewall/router's ICMP will send a redirect back to the client telling it to connect to the internal 192.168.x.x address.
I know that routers handle this type of setup nicely.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.