On 12/23/18 3:47 PM, Daniel Frey wrote:
Hi all,
Hi,
I'm trying to solve a very specific problem where a server on a VLAN
needs to send mail through a VPN it has no direct route to.
Okay.
I feel like that's two distinct things that we don't yet know how they
connect to each other. Just that somehow email from one needs to go
through the other to get to a yet unknown point.
So I figured I can add a route to a different VLAN that this server does
have access to, and that VLAN already has a VPN route to contact the
needed server with.
What are you suggesting adding the route to?
Giving the server a route to get to a different subnet that has VPN
access is not the same as being in said subnet, much less VPN access itself.
So this forwarder would only accept messages from that single IP and
forward it to another single IP.
Now it sounds like you're talking about adding an additional server
that's purpose is to live in the VLAN that does have access to the VPN
and can have communications with the original server configured. Correct?
This new server would function as a mail relay. Am I understanding you
correctly?
Things like SSMTP won't work, as this is a black box that I cannot
install packages such as this. I can configure a mail server IP.
What is the black box? The original server? The receiving server? The
VPN?
It sounds like limitation isn't stopping you from putting the
intermediate MTA in place.
Is postfix the only thing that can do what I need or are there other
solutions?
I would expect that any reasonable MTA can do this. Sendmail (my
preference), Postfix, Qmail, IIS's SMTP service, Mercury Mail,
GroupWise, Exchange, you name it should all be capable of doing this for
you.
You might be able to get away with NAT too.
[A] --- [B] --- === --- [C]
A being the local server
B being the new MTA
C being the destination server
--- network / IP route
=== VPN
You could make A use B as the ""remote server address.
B would be configured to match on SMTP traffic from A and:
- destination NAT to C
- source NAT to B
This way C thinks that B is sending the email.
B would also be configured to match on SMTP traffic from C and:
- destination NAT to A
- source NAT to B
This way A thinks that B is sending the email.
I'm not convinced that you actually need an active MTA in the middle.
I would need to know more about the actual network between systems to be
able to give more details. But there are other options involving MTAs
and / or IP network solutions.
There will be no mailboxes of any sort on this mail relay.
That sort of makes an MTA a heavyweight solution. Especially if
judicious use of source & destination NAT can suffice.
This does not sound like a difficult problem and should be quite
possible to solve a number of different ways.
