Using Discourse in private VPN: What about email?

Installation
1

Hi!

I’d like to use Discourse in a special Setup: The webserver will only be accessible for a number of privately known users inside a VPN. The servers IP will be something like 10.0.0.1, so it is clear that I cannot have a valid public domain name for that.

I’ve read that it’s strongly recommended to setup mail transmission correctly. I’ve also read that you can at least finish the admin account generation with some hacks without email.

I am wondering, what is the best way to go?

a) Setup discourse completely without email. Will that work? I guess, I need to follow at least some sketchy manual procedure to get each account activated, but thats okay for the limited number of users I expect. Would that work? What would be the limitations not having email transmissions working? Of course, I cannot send email notifications (rather small downside for me) - is that all?

b) While the server is using a private IP, I might somehow also have a public address just for email. I expect everything to be optimized (as good as possible) for easy setup, so following some install howtos, I’d enter the server address only once which is then probably used for HTTP redirects etc as well as for SMTP. Is this easy to differentiate? Can I easily setup a server with a private IP address, and a non-matching domain which is only used for mail?

I should state that I haven’t yet acquired any experience with Discourse. I am prepared to look up stuff on my own when I face actual issues. But I see a fundamental choice to be taken here which path to go (a or b) and it would be great to get some advice, to advoid going the wrong path first.

Thanks!

1 Like
2

You need to have a domain name. Discourse won’t run on an ip number.

Can the server access the internet? Building discourse without the internet is… tricky.

If the server can access the internet, then having it be able to send email isn’t a problem.

1 Like
3

Build it on a public connection, add a DNS entry within your VPN to the private IP and then shut down public access.

Don’t use Lets Encrypt as certificate updates will fail.

You won’t be able to easily update it, but if you’re isolating it I’m sure that was already obvious.

Email is central to discourse, all kinds of things won’t work without it.

6 Likes
4

Thanks for trying to help. I guess I have to elaborate a bit more.

First I should explain what part I know well, and which I don’t ;). I do understand the low-level part pretty well. IP adresses, tcp etc. But I have no experience about the things a complex web application does. Also about email: How is an email sender authenticated, how is he checked not to send unathorized spam? (I do not expect you guys to explain all of that to me, just to clarify my questions…)

I do not have a full-blown company VPN infrastructure here, all I currently have is a private vpn subnet and ip-level rules.

Setup is like this: server has a publicly reachable domain, but all ports are closed except for the vpn entry point. Clients connecting to the vpn acquire a 10.0.x.x adress. Server is then reachable on 10.0.0.1:80.

My understanding (and I guess I am wrong here) is, that the server expects to be reachable itself on it’s domain.

Let’s say, I have domain xyz . com which resolves to public ip 8.7.6.5. clients use this domain/ip for the tunnel only. Once the tunnel is setup, their browsers connect to 10.0.0.1.

As I have said, I have no experience with Discourse. What I expect Discouse to use its own domain for are redirect actions. E.g. forwarding new clients which open 10.0.0.1 to 10.0.0.1/login.php. (Or similiar, just as an example). If Discourse would redirect them to xyz . com/login.php instead, they would be lost as the server is not reachable from outside the vpn. This is the type of expected issued I assume an internal address should be configured for.

When it comes to mail, I need to contact external mail servers. Public internet is reachable at any stage! I do not know much about this topic though. I just expect, connecting to a public mail server with “hey, I am 10.0.0.1 please send out some mails for me” will not work as I am using a private IP adress. Here I assume to need a public address.

Reading your answers optimistically, I assume, the configured domain is not used for client HTTP sessions. If the server is reachable under a private IP, and I connect to that IP, all self-referencing links and redirects are relative, so the user is not redirected to the domain the server expects to be connected on. I can just configure xyz.com as domain, and still open Discourse in the browser with 10.0.0.1, without being forwarded to (disfunct) xyz.com addresses.

I hope my question is somewhat clear. Sorry for being so confusing!
Oh, and HTTPS is not required. I even prefer not to use it - I am inside my tunnel and users do not need to be seperated securely. I would like to skip all these issues with cerificates and matching host names.

1 Like
5

That depends on the email server. Let’s suppose you will use a mail service as MailGun, SendGrid, etc. They usually authenticate by an API like URL plus user/password.

There, meanwhile the server can reach outside IPs (only incoming filtering) you shouldn’t have an issue connecting to the mail service.

Specially if the domain resolves to the correct IP.

You’d wouldn’t even need to open the ports for the installation. Because you can reach the domain example.com with the VPN if you have the domain pointing to the private IP when using the VPN Tunnel.

I’m not so sure if Discourse will only use relative URLs, almost certain it won’t. But you change the DNS records in the domain, in such a way you have two A records, one (the first one) pointing to the 10.0.0.1 address, and a second one pointing to the 8.7.6.5 public IP. That might be tricky sometimes when resolving the addresses and cache, and stuff, but you could try.

3 Likes
6

You can have xyz.com resolve to 10.0.0.1.

If the server can reach the internet then the only problem is that you can’t create a let’s encrypt https certificate.

1 Like
7

Here’s a question for you, what does your VPN achieve that SSL would not?

An invite-only discourse instance on SSL already achieves authentication and encryption. What does a VPN add?

3 Likes
8

I have other services running which need to be protected. And I like the idea of having just one non-typical port opened.

But you have a point: I should consider relaxing that requirement, and let Discourse run on the public interface, with SSL.

1 Like
9

Thanks to all of you guys. I guess I got my stuff sorted:

  • For a Webserver running inside the VPN, the VPN server needs to act as DNS also. Internal DNS should resolve the same domain to internal IP, which is publicly resolved to external IP. And I should stop using the servers IP anywhere, let DNS handle this complexity. Currently my VPN is just working on IP level, and I wasn’t even aware about these details.
    Downside: I can mess up the whole www of all users.
  • I could as well have the webserver just running on a public port, and let SSL handle the protection.
    Downside: I am exposed to all the evil of the real world.
3 Likes