1 |
On 12/23/18 3:47 PM, Daniel Frey wrote: |
2 |
> Hi all, |
3 |
|
4 |
Hi, |
5 |
|
6 |
> I'm trying to solve a very specific problem where a server on a VLAN |
7 |
> needs to send mail through a VPN it has no direct route to. |
8 |
|
9 |
Okay. |
10 |
|
11 |
I feel like that's two distinct things that we don't yet know how they |
12 |
connect to each other. Just that somehow email from one needs to go |
13 |
through the other to get to a yet unknown point. |
14 |
|
15 |
> So I figured I can add a route to a different VLAN that this server does |
16 |
> have access to, and that VLAN already has a VPN route to contact the |
17 |
> needed server with. |
18 |
|
19 |
What are you suggesting adding the route to? |
20 |
|
21 |
Giving the server a route to get to a different subnet that has VPN |
22 |
access is not the same as being in said subnet, much less VPN access itself. |
23 |
|
24 |
> So this forwarder would only accept messages from that single IP and |
25 |
> forward it to another single IP. |
26 |
|
27 |
Now it sounds like you're talking about adding an additional server |
28 |
that's purpose is to live in the VLAN that does have access to the VPN |
29 |
and can have communications with the original server configured. Correct? |
30 |
|
31 |
This new server would function as a mail relay. Am I understanding you |
32 |
correctly? |
33 |
|
34 |
> Things like SSMTP won't work, as this is a black box that I cannot |
35 |
> install packages such as this. I can configure a mail server IP. |
36 |
What is the black box? The original server? The receiving server? The |
37 |
VPN? |
38 |
|
39 |
It sounds like limitation isn't stopping you from putting the |
40 |
intermediate MTA in place. |
41 |
|
42 |
> Is postfix the only thing that can do what I need or are there other |
43 |
> solutions? |
44 |
|
45 |
I would expect that any reasonable MTA can do this. Sendmail (my |
46 |
preference), Postfix, Qmail, IIS's SMTP service, Mercury Mail, |
47 |
GroupWise, Exchange, you name it should all be capable of doing this for |
48 |
you. |
49 |
|
50 |
You might be able to get away with NAT too. |
51 |
|
52 |
[A] --- [B] --- === --- [C] |
53 |
|
54 |
A being the local server |
55 |
B being the new MTA |
56 |
C being the destination server |
57 |
|
58 |
--- network / IP route |
59 |
=== VPN |
60 |
|
61 |
You could make A use B as the ""remote server address. |
62 |
|
63 |
B would be configured to match on SMTP traffic from A and: |
64 |
- destination NAT to C |
65 |
- source NAT to B |
66 |
This way C thinks that B is sending the email. |
67 |
|
68 |
B would also be configured to match on SMTP traffic from C and: |
69 |
- destination NAT to A |
70 |
- source NAT to B |
71 |
This way A thinks that B is sending the email. |
72 |
|
73 |
I'm not convinced that you actually need an active MTA in the middle. |
74 |
|
75 |
I would need to know more about the actual network between systems to be |
76 |
able to give more details. But there are other options involving MTAs |
77 |
and / or IP network solutions. |
78 |
|
79 |
> There will be no mailboxes of any sort on this mail relay. |
80 |
|
81 |
That sort of makes an MTA a heavyweight solution. Especially if |
82 |
judicious use of source & destination NAT can suffice. |
83 |
|
84 |
This does not sound like a difficult problem and should be quite |
85 |
possible to solve a number of different ways. |