forwarding ssl port to a different ssl port number on a different machine
Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
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.
SDN 101: An Introduction to Software Defined Networking
Discover the advantages of SDN.
SDN has quickly become one of the hottest trends in IT. But not all SDN solutions offer real software-defined functionality. As more enterprises consider SDN, they want to know, “What is SDN? And what are the real benefits?” If you're ready to explore the advantages of SDN, and want to know how it should be implemented within your enterprise, start by reading our introductory white paper.
Click Here to receive this Complete Guide absolutely free.
forwarding ssl port to a different ssl port number on a different machine
i have had a look through the forum here and can't see anything like the problem i'm going through at the mo - so just asking for advice or how you would tackle this problem.
here it is:
i have 2 mail servers serving ssl encrypted pop3 (port 995) and ssl encrypted smtp (port 465) - they do not allow users to send email through unencrypted smtp port 25.
unfortunately in moving some clients over we have found a problem with a major isp - that is that they filter out the smtp packets sent on port 465 to our servers.
the obvious solution would be to change the ssl smtp port on the servers, but unfortunately this is not a viable option as i have absolutely no control over the servers at all. - i mean i have the physical machines but i do not have any passwords .. etc.
so what i thought the next best idea would be is to use another machine that i have (currently two available with no real tasks (one running debian 3r(something (latest as of 3 days ago)) and one running slackware 11) and use it to serve encrypted ssl on for example port 25 (but any so long as the isp doesnt filter that specific port) and then forward that on to the existing mail servers on port 465 so that basically the client cannot tell the difference and it would be as if they were using the existing mail servers (obviously using a different server name for sending but otherwise...)
i am still very newbie to linux - even tho i have learnt much since i have started using it - and thus have absolutely no idea how to do this without using something like ip cop as the machine to do the port forwarding - except that this wouldnt be ideal as the machines need to be directly out on the internet - not behind a firewall.
i really would appreciate your views on this - the best solution - a program i may need to use - or anything you think helpful.
basically the client cannot tell the difference and it would be as if they were using the existing mail servers
They will also have to enable ssl encryption in spite of talking to port 25. This may confuse users or their software. It might be better to use some high port, like 10465, instead of a well-known port with a slightly different purpose.
it certainly does confuse users unfortunately - but we can deal with their confusion because we can visit most of our clients who have trouble easily and will happily setup the email for them.
we cannot however sort out the issue that 3 in the first 5 users migrated to our new servers were unable to send becuase their isp filtered smtp on 465 (due to spam related issues) now unfortuantely i'm rather junior in the company and the guy who set up the mail servers doesnt have such a grasp on business (the client is right more often than not + and make the client happy)(not to dis him or anything because hes a technical genious - he just doesnt do clients) he says its the clients problem and they've got to deal with it - get a new isp or something - and so he wont change the ports on the server or give me or anyone else access to the servers to change the port.
however - and this is my problem - i could do port forwarding if the mail servers were on an internal network - but they each have seperate WAN ip addresses and connect directly to the web - not through any kind of firewall or anything. so i need something that will do the port forwarding while itself having a WAN ip address and using just that one NIC and that one address to forward the port.
so really im looking for something like wan port 25 to wan port 465 on host...
if this is possible.
Last edited by coal-fire-ice; 03-14-2007 at 05:06 PM.
we cannot however sort out the issue that 3 in the first 5 users migrated to our new servers were unable to send becuase their isp filtered smtp on 465 (due to spam related issues)
Their ISP wants them to talk to the ISP's SMTP server and no one else. (Quite possibly 25 is blocked too.) Of course that's wrong on the ISPs' part, but what can you do? Cheat.
however - and this is my problem - i could do port forwarding if the mail servers were on an internal network - but they each have seperate WAN ip addresses and connect directly to the web - not through any kind of firewall or anything. so i need something that will do the port forwarding while itself having a WAN ip address
Did you try it? What happened? For an experiment, you could just tunnel with ssh (instead of using iptables).
and using just that one NIC and that one address to forward the port.
You can leave out "-i $WAN_IF" then. It shouldn't matter.
Most likely iptables gets installed by default. Try iptables -L; it should list the content of the "filter" table, even if it's quite empty. If iptables is not installed, you get a message to that effect. A command line similar to what you quote should work. (I did not try this; it may need some tweaking, and I don't know how.)
While iptables is the better, more permanent solution, I found it easier to temporarily forward a port using ssh. E.g.,
ssh -g -L 8765:www.google.com:80 localhost
(This forwarding feature can be used to tunnel ports through an ssh connection. When connecting to localhost, the "L"ocal and "R"emote side are the same machine. The -g option, which only works with -L lets you create a gateway, i.e., it listens on all your interfaces, so other clients can use it too.)
Anyway, while that shell is running, anyone can point their browser at http://yourhost:8765, and they'll see exactly what they'd get at www.google.com. I choose the HTTP example because it's easy to see a result.
Note that if you want to listen on a port < 1024 (instead of 8765), you need to run ssh as root, e.g., inside sudo.
Try this experiment (substituting SSL SMTP port 465) to see the forwarding for access to mail servers. BTW, there's one question we haven't addressed: how is traffic distributed across your two servers.
OK, now I did try it out with iptables instead of ssh. This time I forwarded port 8880 of host 192.168.2.5; I had to use an IP address instead of the name for Google. I had this written up when my browser crashed. So here goes again, in short -- I'll be happy to fill in the gaps, so please please ask specific questions.
I needed the following commands, all of which require root privilege (except "echo 1", but writing to /proc does, e.g., by tee)[/B]
You can inspect your chains, before and after modifying them with the above commands by, e.g.,
iptables -L FORWARD
iptables -t nat -L
The ssh solution is simple but ephemeral -- it only lasts as long as the ssh session. With iptables, it stays in effect until you reboot, or remove the rules using iptables -D. And if you save the rules to the right place, the redirection will persist, i.e., it gets re-established at reboot. Different distributions save in different places, e.g., /etc/sysconfig/iptables or /var/lib/iptables/rules-save. However, saving your tables once they work may be as simple as
Otherwise, use some GUI tool (don't ask me!) or read the script /etc/init.d/iptables to find where things are.