public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-user] Mail forwarder on LAN
@ 2018-12-23 22:47 Daniel Frey
  2018-12-24  1:07 ` Grant Taylor
  0 siblings, 1 reply; 8+ messages in thread
From: Daniel Frey @ 2018-12-23 22:47 UTC (permalink / raw
  To: gentoo-user

Hi all,

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.

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.

So this forwarder would only accept messages from that single IP and 
forward it to another single IP.

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.

Is postfix the only thing that can do what I need or are there other 
solutions?

There will be no mailboxes of any sort on this mail relay.

Dan


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gentoo-user] Mail forwarder on LAN
  2018-12-23 22:47 [gentoo-user] Mail forwarder on LAN Daniel Frey
@ 2018-12-24  1:07 ` Grant Taylor
  2018-12-24  2:03   ` Daniel Frey
  0 siblings, 1 reply; 8+ messages in thread
From: Grant Taylor @ 2018-12-24  1:07 UTC (permalink / raw
  To: gentoo-user

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.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gentoo-user] Mail forwarder on LAN
  2018-12-24  1:07 ` Grant Taylor
@ 2018-12-24  2:03   ` Daniel Frey
  2018-12-24  4:21     ` Grant Taylor
  0 siblings, 1 reply; 8+ messages in thread
From: Daniel Frey @ 2018-12-24  2:03 UTC (permalink / raw
  To: gentoo-user

On 12/23/18 5:07 PM, Grant Taylor wrote:
> 
> [A] --- [B] --- === --- [C]
> 
> A being the local server
> B being the new MTA
> C being the destination server
> 
> --- network / IP route
> === VPN
> 

This is correct. A is the voice vlan, the black box is the phone server 
(which I am unable to add custom routes or new software packages to), B 
is another vlan that has access through site-to-site vpn to C.

A needs to send to a mail server on C but it isn't a part of the 
addressing required to traverse through the vpn.

Hence my thought of a mail forwarder.

I've never had to deal with a server in this manner before... needing to 
go through a different vlan/vpn. Hence my thought of a mail relay.

I was messing with source and destination nat but because of the site 
vpn addressing, and the phone server not being in that address range... 
I'm pretty sure that's why it wasn't working.

Dan


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gentoo-user] Mail forwarder on LAN
  2018-12-24  2:03   ` Daniel Frey
@ 2018-12-24  4:21     ` Grant Taylor
  2018-12-24 15:28       ` Daniel Frey
  2018-12-24 15:48       ` Daniel Frey
  0 siblings, 2 replies; 8+ messages in thread
From: Grant Taylor @ 2018-12-24  4:21 UTC (permalink / raw
  To: gentoo-user

On 12/23/18 7:03 PM, Daniel Frey wrote:
> This is correct. A is the voice vlan, the black box is the phone server 
> (which I am unable to add custom routes or new software packages to), B 
> is another vlan that has access through site-to-site vpn to C.

That makes perfect sense.  There is functionally zero hope of modifying 
the phone system.  Even if you could, it would likely compromise 
warranty, other complications ensue.  Let's just consider this a no-fly 
zone.

> A needs to send to a mail server on C but it isn't a part of the 
> addressing required to traverse through the vpn.

Yep.  A LOT of VPNs decide what traffic is interesting and / or allow 
traffic based on source and / or destination subnet.

> Hence my thought of a mail forwarder.

Can the phone server in A talk to a system in B?  Or does the magic need 
to happen on a multi-homed host that is in both the Voice VLAN (A) and 
data VLAN (B)?

> I've never had to deal with a server in this manner before... needing to 
> go through a different vlan/vpn. Hence my thought of a mail relay.

I believe the mail relay, particularly if it's multi-homed in both voice 
and data VLANs, is a viable option.

> I was messing with source and destination nat but because of the site 
> vpn addressing, and the phone server not being in that address range... 
> I'm pretty sure that's why it wasn't working.

Depending where you do it, I would expect that the NAT would work.

Hypothetical scenario:

Voice VLAN = 192.0.2.0/24
Local Data VLAN = 198.51.100.0/24
Remote Data VLAN = 203.0.113.0/24

I'm guessing that you need to get voice messages as attachments from the 
VoIP PBX, 192.0.2.123, to the corporate email server, 203.0.113.234. 
The problem is the site-to-site VPN only allows 198.51.100.0/24 and 
203.0.113.0/24 to communicate.  Meaning that the site-to-site VPN won't 
pass traffic from the VoIP PBX.

Here's an important question:  Does the VoIP PBX have a default gateway 
configured?  Or does it /only/ know about the voice VLAN, 192.0.2.0/24? 
Because if it doesn't have a default gateway, then (what it knows as) 
the mail server will have to be local to the voice subnet.

We already know that the local side of the email solution will have to 
be in the 198.51.100.0/24 subnet to bee able to use the VPN.

You could probably fairly easily have a multi-homed host that is in both 
the Voice VLAN, 192.0.2.252, and the Local Data VLAN, 198.51.100.252.

That would allow you to run an MTA on the multi-homed host and forward 
email at the SMTP application layer.

That would also allow you to use NAT to translate the SMTP traffic as it 
passes between the VoIP PBX and the corporate email server.

Let's say that eth0 is in the Voice VLAN, 192.0.2.252, and that eth1 is 
in the Local Data VLAN, 198.51.100.252.

# Traffic from the VoIP PBX to the corporate email server.
iptables -t nat -A PREROUTING -i eth0 -s $PBXIP -d 192.0.2.252 -p tcp 
--dport 25 -j DNAT 203.0.113.234
iptables -t nat -A POSTROUTING -o eth1 -s $PBXIP -d 203.0.113.234 -p tcp 
--dport 25 -j SNAT 198.51.100.252

# Traffic from the corporate email server to the VoIP PBX.
iptables -t nat -A PREROUTING -i eth1 -s 203.0.113.234 -d 198.51.100.252 
-p tcp --sport 25 -j DNAT $PBXIP
iptables -t nat -A POSTROUTING -o eth0 -s 203.0.113.234 -d $PBXIP -p tcp 
--sport 25 -j SNAT 192.0.2.252

That should get quite close to what you need.  That alters both the 
source and destination IP addresses as the traffic passes through the 
multi-homed host, in each direction.

Aside:  I call that "Double NAT" because it NATs two different addresses 
on one device (as two distinct operations).  But the rest of the world 
thinks "Double NAT" is something else.  :-/


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gentoo-user] Mail forwarder on LAN
  2018-12-24  4:21     ` Grant Taylor
@ 2018-12-24 15:28       ` Daniel Frey
  2018-12-24 15:48       ` Daniel Frey
  1 sibling, 0 replies; 8+ messages in thread
From: Daniel Frey @ 2018-12-24 15:28 UTC (permalink / raw
  To: gentoo-user

On 12/23/18 8:21 PM, Grant Taylor wrote:

> Can the phone server in A talk to a system in B?  Or does the magic need 
> to happen on a multi-homed host that is in both the Voice VLAN (A) and 
> data VLAN (B)?

Yes, I control the router, poking a hole allowing port 25 from the phone 
server IP to the mail relay IP is trivial. This would lessen the need 
for a multi-homed server - although that is possible too as the 
infrastructure is virtualized.

> 
>> I've never had to deal with a server in this manner before... needing 
>> to go through a different vlan/vpn. Hence my thought of a mail relay.
> 
> I believe the mail relay, particularly if it's multi-homed in both voice 
> and data VLANs, is a viable option.
> 
>> I was messing with source and destination nat but because of the site 
>> vpn addressing, and the phone server not being in that address 
>> range... I'm pretty sure that's why it wasn't working.
> 
> Depending where you do it, I would expect that the NAT would work.
> 
> Hypothetical scenario:
> 
> Voice VLAN = 192.0.2.0/24
> Local Data VLAN = 198.51.100.0/24
> Remote Data VLAN = 203.0.113.0/24
> 
> I'm guessing that you need to get voice messages as attachments from the 
> VoIP PBX, 192.0.2.123, to the corporate email server, 203.0.113.234. The 
> problem is the site-to-site VPN only allows 198.51.100.0/24 and 
> 203.0.113.0/24 to communicate.  Meaning that the site-to-site VPN won't 
> pass traffic from the VoIP PBX.
> 
> Here's an important question:  Does the VoIP PBX have a default gateway 
> configured?  Or does it /only/ know about the voice VLAN, 192.0.2.0/24? 
> Because if it doesn't have a default gateway, then (what it knows as) 
> the mail server will have to be local to the voice subnet.
> 
> We already know that the local side of the email solution will have to 
> be in the 198.51.100.0/24 subnet to bee able to use the VPN.
> 
> You could probably fairly easily have a multi-homed host that is in both 
> the Voice VLAN, 192.0.2.252, and the Local Data VLAN, 198.51.100.252.
> 
> That would allow you to run an MTA on the multi-homed host and forward 
> email at the SMTP application layer.
> 
> That would also allow you to use NAT to translate the SMTP traffic as it 
> passes between the VoIP PBX and the corporate email server.
> 
> Let's say that eth0 is in the Voice VLAN, 192.0.2.252, and that eth1 is 
> in the Local Data VLAN, 198.51.100.252.
> 
> # Traffic from the VoIP PBX to the corporate email server.
> iptables -t nat -A PREROUTING -i eth0 -s $PBXIP -d 192.0.2.252 -p tcp 
> --dport 25 -j DNAT 203.0.113.234
> iptables -t nat -A POSTROUTING -o eth1 -s $PBXIP -d 203.0.113.234 -p tcp 
> --dport 25 -j SNAT 198.51.100.252
> 
> # Traffic from the corporate email server to the VoIP PBX.
> iptables -t nat -A PREROUTING -i eth1 -s 203.0.113.234 -d 198.51.100.252 
> -p tcp --sport 25 -j DNAT $PBXIP
> iptables -t nat -A POSTROUTING -o eth0 -s 203.0.113.234 -d $PBXIP -p tcp 
> --sport 25 -j SNAT 192.0.2.252
> 
> That should get quite close to what you need.  That alters both the 
> source and destination IP addresses as the traffic passes through the 
> multi-homed host, in each direction.
> 
> Aside:  I call that "Double NAT" because it NATs two different addresses 
> on one device (as two distinct operations).  But the rest of the world 
> thinks "Double NAT" is something else.  :-/
> 

So it basically comes down to picking a package and then locking it down 
so it only forwards mail to that specific IP, and only allows mail to be 
received from the phone server.

It would be easier to use the public IP but due to regulations it has to 
go over the VPN.

Dan


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gentoo-user] Mail forwarder on LAN
  2018-12-24  4:21     ` Grant Taylor
  2018-12-24 15:28       ` Daniel Frey
@ 2018-12-24 15:48       ` Daniel Frey
  2018-12-24 16:40         ` Grant Taylor
  1 sibling, 1 reply; 8+ messages in thread
From: Daniel Frey @ 2018-12-24 15:48 UTC (permalink / raw
  To: gentoo-user

On 12/23/18 8:21 PM, Grant Taylor wrote:
> I'm guessing that you need to get voice messages as attachments from the 
> VoIP PBX, 192.0.2.123, to the corporate email server, 203.0.113.234. The 
> problem is the site-to-site VPN only allows 198.51.100.0/24 and 
> 203.0.113.0/24 to communicate.  Meaning that the site-to-site VPN won't 
> pass traffic from the VoIP PBX.
> 
> Here's an important question:  Does the VoIP PBX have a default gateway 
> configured?  Or does it /only/ know about the voice VLAN, 192.0.2.0/24? 
> Because if it doesn't have a default gateway, then (what it knows as) 
> the mail server will have to be local to the voice subnet.

Was a little hasty posting...

Yes the new server emails voice messages as attachments. It also does 
things like tracking staff status (in office, away, etc) and so it has 
other notifications relating to that and some other features.

The VoIP PBX has a gateway; it is using sip trunks to provide phone 
service. However, it will be severely locked down on install, I will 
only let it talk to the sip trunk provider and its update server and 
nothing else.

Dan


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gentoo-user] Mail forwarder on LAN
  2018-12-24 15:48       ` Daniel Frey
@ 2018-12-24 16:40         ` Grant Taylor
  2018-12-24 17:32           ` Daniel Frey
  0 siblings, 1 reply; 8+ messages in thread
From: Grant Taylor @ 2018-12-24 16:40 UTC (permalink / raw
  To: gentoo-user

On 12/24/18 8:48 AM, Daniel Frey wrote:
> Was a little hasty posting...

That happens.

> Yes the new server emails voice messages as attachments. It also does 
> things like tracking staff status (in office, away, etc) and so it has 
> other notifications relating to that and some other features.
> 
> The VoIP PBX has a gateway; it is using sip trunks to provide phone 
> service. However, it will be severely locked down on install, I will 
> only let it talk to the sip trunk provider and its update server and 
> nothing else.

Does "I will only let the VoIP talk to the SIP trunk provider and it's 
update server" mean that the VoIP PBX won't be able to talk to the 
intermediate mail server that you're talking about building?  Or would 
you also allow the VoIP PBX to talk to the intermediate mail server?

This is a critical question as it determines if the intermediate mail 
server needs to be in the same subnet as the VoIP PBX or not.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gentoo-user] Mail forwarder on LAN
  2018-12-24 16:40         ` Grant Taylor
@ 2018-12-24 17:32           ` Daniel Frey
  0 siblings, 0 replies; 8+ messages in thread
From: Daniel Frey @ 2018-12-24 17:32 UTC (permalink / raw
  To: gentoo-user

On 12/24/18 8:40 AM, Grant Taylor wrote:
> On 12/24/18 8:48 AM, Daniel Frey wrote:
>> Was a little hasty posting...
> 
> That happens.
> 
>> Yes the new server emails voice messages as attachments. It also does 
>> things like tracking staff status (in office, away, etc) and so it has 
>> other notifications relating to that and some other features.
>>
>> The VoIP PBX has a gateway; it is using sip trunks to provide phone 
>> service. However, it will be severely locked down on install, I will 
>> only let it talk to the sip trunk provider and its update server and 
>> nothing else.
> 
> Does "I will only let the VoIP talk to the SIP trunk provider and it's 
> update server" mean that the VoIP PBX won't be able to talk to the 
> intermediate mail server that you're talking about building?  Or would 
> you also allow the VoIP PBX to talk to the intermediate mail server?
> 
> This is a critical question as it determines if the intermediate mail 
> server needs to be in the same subnet as the VoIP PBX or not.
> 


In that case I meant restrictions to the general internet; it'll only 
talk to the sip provider's IP and the update server IP. It'll have a 
separate rule to allow it to talk to the other vlan where the smtp 
forwarder will reside.

Dan


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2018-12-24 17:32 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-12-23 22:47 [gentoo-user] Mail forwarder on LAN Daniel Frey
2018-12-24  1:07 ` Grant Taylor
2018-12-24  2:03   ` Daniel Frey
2018-12-24  4:21     ` Grant Taylor
2018-12-24 15:28       ` Daniel Frey
2018-12-24 15:48       ` Daniel Frey
2018-12-24 16:40         ` Grant Taylor
2018-12-24 17:32           ` Daniel Frey

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox