Subnet

[subven]

Is there a reason you don't want to point all domains to your Cloudron IP address? AFAIK Cloudron is designed to use just one IPv4/IPv6 address. You can have multiple network interfaces but Cloudron will only listen to one of them. See the docs for more details.

[robi]

You may also wish to set up IP aliases on the Cloudron IP interface ex: eth0:[0-3], so all IPs go there.

[girish]

As @subven said, the code currently handles only one IPv4/IPv6 address. I would also be interested in knowing why you would want to assign multiple IPs though to the server.

[krumel]

@girish
I am not OP, but wouldn't that be useful to provide some Apps to an internal network and some for an external network only?

[girish]

@krumel Indeed, that would be possible if the server has NICs - one internal and one external. Is this setup common in practice?

[krumel]

@girish
Well, especially in setups where Cloudron is on a VM I recon it is somewhat common - just from Reddit alone I know quite a few people who use a similar setup to mine:

Personally my instance is on a Proxmox host in a DMZ,we have separate networks for purely internal services and for non-cloudron external services (and a purely management network as well). For some services we use MacVLAN on docker to provide separate IPs for containers.
While this absolutely could be achieved with VLANs as well, in a Proxmox environment it was easier to use "physically" separate networks and route them properly through an OPN Sense VM.

In theory one surely could use two Cloudron instances, but that would first be quite expensive, but also limit some backend functionality imho.

Kind regards,
Phil

[subven]

In the "common" scenario you maintain an network internal DNS server that routes traffic for some requests or (sub)domains to internal resources for security, development or testing purposes. Similiar to what you could do with your hosts file but at network level where sometimes resources are only accessible via VPN. Every request that is not served by the internal DNS will be forwarded to the external (real) DNS server that is in charge of the domain.

There are some cases where you separate traffic with NICs (like for management interfaces) but in case of Cloudron this could already be solved by unbound. Most use cases are solveable this way and there is already documentation present.

Lets say you don't want to expose the dashboard to the public. You can block the routing to my.domain.com (or wherever your dashboard is at) with your network or VPS providers firewall for sure. In some cases you will lose access as well and other services can be affected so maaaaybe it could help to seperate services to different NICs....but personally I'm fine with the way Cloudron works.

[krumel]

@subven
Security wise that is a quite limited scenario.
This would mean that internal clients would need external access for services that are both internal and external- a scenario that is often undesired.
DNS is never a security measure.

[girish]

@krumel Can you make a feature request post? Can look into this.

[krumel]

@girish
As requested:
https://forum.cloudron.io/topic/7839/more-than-1-network-nic-bind-container-to-networks/1

[girish]

@krumel thanks!