Drafted ip-and-dns-on-interconnected-vpn

master
Keith Irwin 2023-04-08 20:45:23 -06:00
parent 4dafaf300d
commit 1c523b2575
Signed by: ki9
GPG Key ID: DF773B3F4A88DA86
1 changed files with 534 additions and 0 deletions

View File

@ -0,0 +1,534 @@
---
title: "IP and DNS standards for interconnected VPNs"
author: "Keith Irwin <ki9@gf4.pw>"
status: Proposed
---
#### Abstract
This standard specifies a convention for host addressing and domain namespacing on interconnected virtual private networks (VPNs). The standard covers the assignment of internet protocol (IP) addresses using sane subnetworks for efficient routing within and between meshed VPNs. Best practices are provided for centralized (hub-and-spoke) routing, as well as direct client host connections. Later, the document describes proper allocation of domain and subdomain names on a private top-level zone, providing fully-qualified domain names for the private IPs on the VPNs. Finally, suggestions are provided for using these domains for SSL certificates, mailservers, web proxies, and other existing web protocols.
#### Table of Contents
[1. Introduction](#1.-introduction) \
[1.1. Notational conventions](#1.1.-notational-conventions) \
[1.1.1. Requirements notation](#1.1.1.-requirements-notation) \
[1.1.2. Definitions](#1.1.2.-definitions )
[1.2. Structure of this document](#1.2.-structure-of-this-document) \
[2. Virtual Private Network](#2.-virtual-private-network) \
[2.1. Software](#2.1.-software) \
[2.2. Address allocation](#2.2.-address-allocation) \
[2.2.1. IPv4](#2.2.1.-ipv4) \
[2.2.2. IPv6](#2.2.2.-ipv6) \
[2.3. Topology](#2.3.-topology) \
[2.3.1. Hub-and-spoke routing](#2.3.1.-hub-and-spoke-routing) \
[2.3.2. Peer-to-peer routing](#2.3.2.-peer-to-peer-routing) \
[3. Domain name service](#3.-domain-name-service) \
[3.1. User domain names](#3.1.-user-domain-names) \
[3.2. Server domain names](#3.2.-server-domain-names) \
[3.3. Wildcard CNAMEs](#3.3.-wildcard-cnames) \
[4. Certificate authority](#4.-certificate-authority) \
[5. Proposal for a names and numbers authority](#5.-proposal-for-a-names-and-numbers-authority) \
[6. Procedural Information](#6.-procedural-information) \
[6.1. Security considerations](#6.1.-security-considerations) \
[6.2. Configuration considerations](#6.2.-configuration-considerations) \
[Appendix A. Example configurations](#appendix-a.-example-configurations) \
[A.1. Bind9 nameserver](#a.1.-bind9-nameserver) \
[A.2. UFW firewall](#a.2.-ufw-firewall) \
[A.3. Nginx proxy to dev server](#a.3.-nginx-proxy-to-dev-server) \
[A.4. Nginx proxy from the internet to a client host](#a.4.-Nginx-proxy-from-the-internet-to-a-client-host) \
[A.5. Postfix relay from the internet to a client host](#a.5.-postfix-relay-from-the-internet-to-a-client-host)
## 1. Introduction
### 1.1. Notational conventions
#### 1.1.1. Requirements notation
This document occasionally uses terms that appear in capital letters. When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD NOT", and "MAY" appear capitalized, they are being used to indicate particular requirements of this specification. A discussion of the meanings of these terms appears in [[RFC2119]](https://www.rfc-editor.org/rfc/rfc2119).
#### 1.1.2. Definitions
This document uses the following terms in respect to their subsequently provided definitions.
**`Classless Inter-Domain Routing` or `CIDR`** A notation for describing subnetwork address space, as per [[RFC4632]](https://www.rfc-editor.org/rfc/rfc4632)
**`VPN` or `virtual private network`** A virtual IP network operating in accordance with [[RFC1918]](https://www.rfc-editor.org/rfc/rfc1918) that lets devices connect to each other as if on a "virtual LAN".
**`hub-and-spoke` or `HAS`** A type of network topology where a single host acts as a central server (hub) for other client hosts (spokes).
**`intervpn`** Anything related to network connections and communication *among* VPNs
**`intravpn`** Anything related to network connections and communication *within* a VPN
**`client` or `device`** A user's wireguard-connected network host which acts as a "spoke" in its local HAS network.
**`server`** A community's device which acts as a hub in the local HAS network and, possibly, as a gateway to the wider intervpn network.
**`user`** A member of an internet community, who may control multiple client hosts (computers, phones, etc).
**`community` or `tilde`** Any private internet community that manages a virtual private network for multiple users.
**`NS` or `nameservers`** DNS nameservers run by communities in accordance with [[RFC1035]](https://www.rfc-editor.org/rfc/rfc1035).
**`Top-level domain` or `TLD`** The highest level of the domain name system. Well-known TLDs include ".com" and ".org", but this document mainly refers to "private" TLDs that are not recognized by the Internet Assigned Numbers Authority (IANA)'s root nameservers.
**`CA` or `certificate authority`** A community acts as a CA by signing SSL/TLS certificates for their private TLD per [[RFC5280]](https://www.rfc-editor.org/rfc/rfc5280).
**`Store now, decrypt later` or `SNDL`** A type of encryption attack that involves storing encrypted transmissions in data centers so that they can be decrypted in the future with better technology, namely, quantum computers.
### 1.2. Structure of this document
This document is divided into several sections.
This section, [**section 1**](#1.-introduction), is a short introduction to the document.
[**Section 2**](#2.-virtual-private-network) describes IP standards for communities to manage interconnected VPNs.
[**Section 3**](#3.-domain-name-service) specifies a convention for allocating private domain names pointing to private IP addresses.
[**Section 4**](#4.-certificate-authority) describes how a tilde can sign SSL/TLS certificates for users, and how they could be used.
[**Section 5**](#5.-proposal-for-a-names-and-numbers-authority) proposes the formation of an authority to manage intervpn assigned names and numbers.
[**Section 6**](#6.-procedural-information) mentions security implications of the standard and warns of potentially breaking configuration changes.
[**Appendix A**](#appendix-a.-example-configurations) has some example configurations showing various best practices and use-cases for the network described in this document.
## 2. Virtual Private Network
### 2.1. Software
Communities MUST use the latest stable version of [wireguard VPN software](https://www.wireguard.com/). VPN connections MUST implement quantum-resistant symmetric-key encryption to protect users from SNDL attacks. This can be done in wireguard by setting `PSK`s in every `[Peer]` section (see the examples in [Section 2.3](#2.3.-topology)).
When generating user configs for wireguard, the server MUST NOT keep the client's private key anywhere on the server, including logfiles. It is to be sent to the user and forgotten.
Clients' new configurations MUST be sent to the user through a strongly-encrypted channel such as an existing wireguard connection, PGP-encrypted email, signal messenger, matrix/telegram encrypted room, etc. (A non-vpn https connection SHOULD NOT be used).
### 2.2. Address allocation
Communities MUST allocate either an IPv4 address, an IPv6 address, or both, to every host on their VPN. The IPs SHOULD be created in accordance with the standards outlined in this section. Ideally, a community MAY provide both addresses until IPv4-space is exhausted, and only IPv6 addresses after that.
#### 2.2.1. IPv4
[Section 3 of [RFC1918]](https://www.rfc-editor.org/rfc/rfc1918#page-4)] describes 3 IP spaces The Internet Assigned Numbers Authority (IANA) has reserved three IPv4 address spaces for private use:
- `10/8`
- `172.16/12`
- `192.168/16`
Of these, only `10/8` is big enough to contain an organized network of multiple internet communities. Communities that want to interconnect MUST use this subnet to allocate IP addresses to both servers and clients. Communities SHOULD allocate IPv4 addresses of the form `10.x.y.z` to user hosts, where `x`, `y`, and `z` are integers of the form `1 ≤ I ≤ 254` and:
- **`x`** determines a community's entire `10.x/16` network
- **`y`** determines a user's `10.x.y/24` network or
- **`z`** determines a single host, `10.x.y.z/32`.
The special case of `y=0` and the respective network `10.x.0/24` SHOULD be reserved servers. Thus, a community's first server is typically addressed `10.x.0.1`.
**For example:** Your home pc could be `10.11.1.1` and your phone `10.11.1.2`. After configuring wireguard, you can use either device to ping your friend, whose pc is at `10.11.2.1`.
#### 2.2.2. IPv6
IPv6 MAY be implemented, where IP addresses SHOULD take the form `fd69:1337:0:420:f4:x:y:z`. This `/80` network SHOULD be organized as above, except `x`, `y`, and `z` are now hexadecimal numbers of the form, `0 ≤ H ≤ ffff`. Thus,
- Several communities can use the `fd69:1337:0:420:f4::/80` network
- Each community gets a network of the form `fd69:1337:0:420:f4:x::/96`
- Each community can host their servers on `fd69:1337:0:420:f4:x::/112`
- Each user gets a `fd69:1337:0:420:f4:x:y::/112` network for their devices
### 2.3. Topology
The proposed topology of the network is a mesh internetwork where each mesh node is a community's server, and each of these servers acts as a hub for the community's users' devices. Thus, servers act as a gateway between the local vpn and the greater intervpn network. This default topology allows users to permissionlessly create their own p2p connections between their clients, reducing latency and improving decentralization.
#### 2.3.1. Hub-and-spoke routing
Wireguard configurations provided to users SHOULD be configured by default to route traffic from one client to another through the central hub server. This allows newly-connected devices to ping each other without further configuration.
**Figure 2.3.1.a. Intervpn HAS routing**
```
+===========+ +=============+
| myserver +--------+ otherserver |
| 10.11.0.1 | | 10.13.0.1 |
+=+=======+=+ +======+======+
| | |
+=========+=+ +=+=========+ +====+======+
| mypc | | myphone | | friendpc |
| 10.11.1.1 | | 10.11.1.2 | | 10.13.1.1 |
+====+======+ +===========+ +====+======+
```
**For example** In Figure 2.3.1.a, `myserver` and `otherserver` represent two communities' servers and the three other blocks represent users' clients. It is clear from the diagram that a connection from `myphone` to `friendpc` will be routed through both servers. The routing may seem complicated, but the organized subnetting makes the configuration simple. Each of the two servers will have wireguard configs like this:
**`myserver:/etc/wireguard/mynet.conf`**
```
[Interface] # myserver
PrivateKey = XXXXXXXX
Address = 10.11.0.1/8 # Use /16 to close intervpn gateway
ListenPort = 42069 # Needs to be open
[Peer] # otherserver
PublicKey = XXXXXXXX
PresharedKey = XXXXXXXX
AllowedIPs = 10.13.0.0/16 # Route 10.13/16 traffic to this peer
[Peer] # mypc
PublicKey = XXXXXXXX
PresharedKey = XXXXXXXX
AllowedIPs = 10.11.1.1/32 # Internal host: talk to it directly
[Peer] # myphone
PublicKey = XXXXXXXX
PresharedKey = XXXXXXXX
AllowedIPs = 10.11.1.2/32 # Internal host: talk to it directly
```
And each client is given a default config like this:
**`mypc:/etc/wireguard/mynet.conf`**
```
[Interface] # mypc
PrivateKey = XXXXXXXX
Address = 10.11.1.1/8
[Peer] # myserver
PublicKey = XXXXXXXX
PresharedKey = XXXXXXXX
AllowedIPs = 10.0.0.0/8 # Send all intervpn traffic to myserver
Endpoint = 9.8.7.6:42069 # Change to the server's public IP
PersistentKeepAlive = 25 # If mypc is behind NAT
```
#### 2.3.2. Peer-to-peer routing
The setup in section 2.3.1 is not ideal due to the number of hops involved. Wireguard decrypts the data on each server hop so it's not end-to-end encrypted either.
Users may choose to improve their default configurations by setting up direct connections to other clients.
**Figure 2.3.2.a. Intervpn routing with p2p connections**
```
+===========+ +=============+
| myserver +--------+ otherserver |
| 10.11.0.1 | | 10.13.0.1 |
+=+=======+=+ +======+======+
| | |
+=========+=+ +=+=========+ +====+======+
| mypc | | myphone | | friendpc |
| 10.11.1.1 +---+ 10.11.1.2 | | 10.13.1.1 |
+====+======+ +===========+ +====+======+
| |
+------------------------------+
```
In figure 2.3.2.a, two p2p connections have been created, mypc<->myphone and mypc<->friendpc. A peer connection can be created between any two clients on any network, without requiring mediation from admins or server-side processes. The two users simply share their VPN IP addresses, external (internet) IP addresses, and a newly-generated PSK.
The configuration changes required by the clients depends on whether the clients have their external UDP wireguard listen port exposed to the internet or not. If the device is behind a home router, as most are, this can be done with port forwarding or direct IPv6 routing. It's typically not possible at all on mobile-network-connected devices.
1. If both clients have an open endpoint, no keep-alive packets are required.
2. If only one client has an open endpoint, the other client will need to maintain the connection by sending periodic keep-alive packets.
3. If neither client has an open endpoint, direct connections are not possible and the HAS method must be used.
The first scenario (1.) is ideal because no data are transmitted if the two clients are "at rest". Wireguard is an inherently "quiet" protocol that does not send any healthchecks or keepalives by default.
**For example,** assuming case (2.) where `myphone` is a mobile device with roaming IP addresses that never permits port forwarding and `mypc` *does* have port forwarding to wireguard port `51820` from its global IP, `1.2.3.4`. A direct connection with keep-alive packets would look something like this:
**mypc:/etc/wireguard/mynet.conf**
```
[Interface] # mypc
PrivateKey = XXXXXXXX
Address = 10.11.1.1/8
[Peer] # myserver
PublicKey = XXXXXXXX
PresharedKey = XXXXXXXX
AllowedIPs = 10.0.0.0/8
Endpoint = 9.8.7.6:42069
[Peer] # myphone
PublicKey = XXXXXXXX
PresharedKey = XXXXXXXX
AllowedIPs = 10.11.1.2/32
```
**`myphone` config imported to wireguard app**
```
[Interface] # myphone
PrivateKey = XXXXXXXX
Address = 10.11.1.2/8
[Peer] # myserver
PublicKey = XXXXXXXX
PresharedKey = XXXXXXXX
AllowedIPs = 10.0.0.0/8
Endpoint = 9.8.7.6:42069
PersistentKeepAlive = 25
[Peer] # mypc
PublicKey = XXXXXXXX
PresharedKey = XXXXXXXX
AllowedIPs = 10.11.1.1/32
Endpoint = 1.2.3.4:51820
PersistentKeepAlive = 25
```
Connections from one client to another will default to the direct connection because the `/32` address in the p2p peer's AllowedIPs is more specific than the `/8` address in the server's section. Notably, the configurations don't need to change much from the default presented in section 2.3.1; each client just needs a new `[Peer]` section for the new connection.
## 3. Domain name service
A community MUST provide a domain name service for the IP addresses assigned in [Section 2.2](#2.2.-address-allocation). The nameserver MUST serve names on a single predetermined TLD. The TLD could be anything that isn't already a global TLD like `.com` or a TLD already taken by another community. (see proposal x for a proposal to maintain a central directory of communities).
The community's nameserver MUST accept fDNS queries on subdomains for these private TLDs and provide VPN IP addresses as answers. The nameserver MUST also provide reverse DNS or "rDNS", so VPN IP addresses can be queried to determine the hostname/username/community associated with a given address.
The nameserver MUST NOT accept queries from the global internet. The nameserver MUST only accept fDNS and rDNS queries from their VPN or other tildes' VPNs. (Recommended nameserver configurations can be found in [appendix A.1](#a.1.-bind9-nameserver)).
Users MAY set a search domain in their network configurations to associate a TLD with the correct VPN network interface.
### 3.1. User domain names
User device domain names MUST follow a hierarchical subdomain structure, `A.B.C`, where:
- `C` is the community's TLD
- `B` is the username
- `A` is hostname of the device
**For example:** Your home pc could be `pc.myuser.mynet` and your phone `phone.myuser.mynet`. Either can ping up `pc.myfriend.mynet`. These domains would simply point to the corresponding IP addresses from the example in [Section 2.2.1](#2.2.1.-ipv4).
### 3.2. Server domain names
Designated server domain names MAY follow this convention, using a predetermined value for `B` such as `srv`. Alternatively, servers may take the form `A.C` as above. If this latter method is used, administrators MUST ensure that no server is assigned a hostname that matches a preexisting user name, and likewise, that users MUST NOT be created with usernames that match preexisting server hostnames.
### 3.3. Wildcard CNAMEs
When assigning host domain names, all first-level subdomains SHOULD be automatically linked to the domain name by a wildcard subdomain CNAME.
**For example:** `*.mypc.myuser.mynet` CNAMEs to `mypc.myuser.mynet` and `*.myserver.mynet` CNAMEs to `myserver.mynet`.
This can be done at the same time that the A and AAAA records are created for the domain. The wildcard subdomain CNAME assignment makes virtual hosting multiple services on a single host much easier.
## 4. Certificate authority
A community SHOULD provide a certificate authority service. The community SHOULD serve private services over encrypted SSL connections such as HTTPS whenever possible, even though the wireguard tunnel is already encrypted. This is because the SSL layer adds additional validation in addition to encryption.
Users SHOULD be provided with an SSL certificate and key for each of their connected devices. The certificate SHOULD include all IPs, domains, and subdomains associated with the host in the Subject Alternative Names section per [Section 4.2.1.6 of [RFC1035]](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.6).
**For example:** The certificate for `mypc` should have a `[SAN]` section like this:
```
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:mypc.myuser.mynet, DNS:*.mypc.myuser.mynet, IP Address:FD69:1337:0:420:f4:11:1:2, IP Address:10.11.1.2
```
That way, the same certificate can be used for https on any of these addresses:
- `https://10.11.1.2/`
- `https://[fd69:1337:0:420:f4:11:1:2]/`
- `https://mypc.myuser.mynet/`
- `https://myservice.mypc.myuser.mynet/`
- `https://myotherservice.mypc.myuser.mynet/`
- `https://anyotherservice.mypc.myuser.mynet/`
## 5. Proposal for a root authority
To prevent conflicting community IP networks and domains names, a central, democratically-goverened assigned names and numbers authority should be created. In addition, it could serve as root authorities for SSL and DNS. This guide so far has described the community's server as being both the certificate authority and root nameserver on the zone. The problem with this is that users of the intervpn will need to add a nameserver for every TLD they want to make lookups on, and they will need to import a different ca certificate for each one too.
This is at least a decentralized, working, upgradable system. A good upgrade would be for a central authority to sign each community's CA, which in turn signs the device certificates. The X.509 spec [[RFC5280]](https://www.rfc-editor.org/rfc/rfc5280) is designed for this sort of hierarchical CA structure. Likewise, the DNS system could have another hierarchical layer of one or more intervpn root name servers.
To recap, needed central functions of this authority are:
- Allocation of TLDs to communities
- Allocation of IP subnets to communities
- Root certificate authority
- Root domain nameserver
- Democratic self-governance with checks and balances
This is all out-of-scope of this document so a future RFC will have to provide all these details. Until then, communities can manage their own CAs and nameservers and make a best-effort to collaborate to avoid number- and namespace collisions.
## 5. Procedural Information
### 6.1. Security considerations
While home NAT gateways can be an impediment to mobile access to self-hosted services, they also provide a firewall layer between private devices and the wild wild internet. Connecting a device to a large vpn with many unknown users is a security risk that mandates mitigation with proper firewalling and routing. System operators need to take care that their system is configured correctly and should educate their users on proper packet management practices. The firewall rules and configurations in [Appendix A](#appendix-a.-example-configurations) show good examples of packet filtering rules in various programs.
### 6.2. Configuration considerations
This RFC does not improve a previous RFC so no revisions to previously conformant configurations are required. However, existing VPN and nameserver configs may require breaking changes to become compliant. See [Appendix A](#appendix-a.-example-configurations) for recommended configuration samples.
## Appendix A. Example configurations
### A.1. Bind9 nameserver
The `allow-query` line tells [bind9](https://www.isc.org/bind/) to only answer queries on the intervpn at `10/8`. This setting is zone-specific and will not affect other zones, including public zones.
**`myserver:/etc/bind/named.conf.local`**
```bind9
// Set acl
acl "intervpn" { 10.0.0.0/8; };
acl "ourvpn" { 10.11.0.0/16; };
// Forward DNS
zone "mynet" {
type master;
file "path/to/mynet.db";
allow-query { localhost; localnets; intervpn; }; // Who can query .mynet domains
allow-transfer { 10.11.0.2; }; // Slave servers AND dashboards that read axfr answers
also-notify { 10.11.0.2; }; // Explicitly notify those slaves of changes
update-policy { // Keys that can nsupdate .mynet domains
grant myadmin zonesub ANY;
grant mydashboard zonesub ANY;
};
};
// IPv4 reverse DNS
zone "11.10.in-addr.arpa" {
type master;
file "path/to/10.11.db";
allow-query { localhost; localnets; intervpn; };
allow-transfer { 10.11.0.2; };
also-notify { 10.11.0.2; };
update-policy { // Keys that can do rDNS nsupdates
grant myadmin zonesub ANY;
grant mydashboard zonesub ANY;
};
};
```
### A.2. UFW firewall
Some examples of `ufw` ("uncomplicated firewall") commands to filter network packets. These examples assume a local VPN IP address of `10.11.1.1`. A default deny rule is presupposed.
**`mypc` root shell**
```sh
# ufw allow from 10.11.1.0/24 to 10.11.1.1 \
port 22 proto tcp comment "ssh from my devices"
# ufw allow from 10.11.2.0/24 to 10.11.1.1 \
port 22 proto tcp comment "ssh from my friend's devices"
# ufw allow from 10.11.0.0/16 to 10.11.1.1 \
port 443 proto tcp comment "share dev server with local tilde"
# ufw allow from 10.0.0.0/8 to 10.11.1.1 \
port 25 proto tcp comment "let anyone in the intervpn send mail"
```
### A.3. Nginx proxy to dev server
This [nginx](https://nginx.org/) configuration allows a user and that user's friend to access the user's dev server over the VPN. This development website is made available on any of the two users' devices at `https://dev.mypc.myuser.mynet` and points to a web server running on port 8080 of the user's pc.
**`mypc:/etc/nginx/sites-enabled/dev-server.conf`**
```nginx
server {
server_name dev.mypc.myuser.mynet;
listen 10.11.1.1:443 ssl http2;
ssl_certificate /path/to/downloaded/mypc.myuser.mynet/server.crt;
ssl_certificate_key /path/to/downloaded/mypc.myuser.mynet/server.key;
ssl_stapling off;
allow 10.11.1.0/24; # My devices
allow 10.11.2.0/24; # My friend's devices
deny all; # Nobody else
# Proxy to local dev server
location / {
proxy_pass http://localhost:8080;
}
}
```
Using this method is a handy way to test designs on a mobile device, so long as the device is on wireguard and listed in one of nginx's `allow` line. Note that this configuration is installed on a client PC and requires no permission from a server.
### A.4. Nginx proxy from the internet to a client host
A server can act as a web gateway from the greater intervpn as well as the greater internet. In this example, myuser is hosting a website on the global internet at `https://myuser.example.org/` but wants to self-host their `public_html` directory on their home pc. Maybe their ISP doesn't allow port-forwarding or static IPs. The web service can be proxied by having a webserver running on both the server and the pc.
**`myserver:/etc/nginx/sites-enabled/myuser.conf`**
```nginx
server {
server_name myuser.example.org;
listen 443 ssl http2;
ssl_certificate /etc/letsencrypt/live/myuser.example.org/server.crt;
ssl_certificate_key /etc/letsencrypt/live/myuser.example.org/server.key;
location / {
proxy_pass http://10.11.1.1;
}
}
```
**`mypc:/etc/nginx/sites-enabled/www.conf`**
```nginx
server {
listen 10.11.1.1:80 http2 default_server;
location / {
root /var/www/public_html;
}
}
```
The client has to have port `443/tcp` open to `10.11.0.1` of course. And make sure `mypc` has a decent uptime!
### A.5. Postfix relay from the internet to a client host
The typical method of delivering mail to users over a VPN is by closing all ports except 25 to the internet, so that mail retrieval through imaps/pop and sending over 587/smtp can only be done over the vpn. However, users may prefer to keep emails on their own pc where they are safe. Thus, it might be better to simply relay mail from the internet to a user's pc over the vpn.
[Postfix](https://www.postfix.org/) has good documentation ([Standard configuration: Email firewall/gateway](https://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall)) on how to configure a gateway "firewall" host that forwards traffic between the internet and a local network. This example is similar but uses our VPN as the "local network".
**`myserver:/etc/postfix/main.cf`**
```postfix
mydomain = example.org
myhostname = myserver.$mydomain
myorigin = $mydomain
# Whose mail we relay to outside networks
# Don't run an "open relay"!
mynetworks = 127.0.0.0/8, 10.11.0.0/16
smtpd_relay_restrictions =
permit_mynetworks reject_unauth_destination
# No local delivery
mydestination =
local_recipient_maps =
local_transport = error:No local delivery
# Receive mail to these domains and subdomains thereoff
relay_domains = mynet $mydomain
# Receive mail to these addresses (see below)
relay_recipient_maps = hash:/etc/postfix/relay_recipients
# Where to forward emails (see below)
transport_maps = hash:/etc/postfix/transport
# Mail aliases (i.e. postmaster)
virtual_alias_maps = hash:/etc/postfix/virtual
```
The list of mail addresses address to relay (drop the rest)
**`myserver:/etc/postfix/relay_recipients`**
```
@example.org x
@myuser.example.org x
@mynet x
@myuser.mynet x
```
Where to send myuser's mail
**`myserver:/etc/postfix/transport`**
```
myuser@example.org relay:[mypc.myuser.mynet]
myuser.example.org relay:[mypc.myuser.mynet]
myuser@mynet relay:[mypc.myuser.mynet]
myuser.mynet relay:[mypc.myuser.mynet]
```
And on the client designated to receive the mail:
**`mypc:/etc/postfix/main.cf`**
```postfix
mydomain = myuser.mynet
myhostname = mypc.$mydomain
myorigin = $myhostname
inet_interfaces = $myhostname, localhost
mydestination = mypc, localhost, mypc.myuser.mynet,
myuser.mynet, example.org, myuser.example.org
mynetworks = 127.0.0.0/8, 10.0.0.0/8
relayhost = [myserver.mynet] # Where to send outgoing mail
alias_maps = hash:/etc/aliases # Probably alias everything to myuser
alias_database = $alias_maps
home_mailbox = mail # Where in your homedir to put mail
luser_relay = myuser # Mail with unknown destination is sent here
```