Sites reaching each other

What you will achieve

When to use this

What you need

Before you start

Setup

1. 1

   Write down every subnet and every direction

   Before touching the dashboard, write down two lists:

   • Every site's subnets. No two may overlap: a client asked for 192.168.1.0/24 cannot tell which site you meant. Publishing single machines does not get around it; renumbering does. Include your organization's tunnel range, a /16 inside 100.64.0.0/10: the Address row of sxaccess info shows it once a device has joined.
   • Which site reaches what, one sentence per direction. Frankfurt reaches the Munich database. Munich reaches nothing in Frankfurt. Each sentence becomes one access rule.

   Why first: a collision is cheap to fix now and expensive at the third site.

2. 2

   Enrol a routing device at each site

   At each site, pick one always-on Linux host on the LAN with iptables or nftables. The agent rewrites addresses with them and turns IP forwarding on by itself.

   Create its key in Access › Enrollment keys › Create enrollment key:

   • Name - router-muc.
   • Make this key reusable, Temporary devices, Allow Extra DNS Labels - off.
   • Expires in - 1 day. You use the key in a minute.
   • Auto-assigned groups - type site-muc and press Enter: the group is created, and the host joins it as it enrols.

   Press Create enrollment key and copy the key: it is shown only once. Then open a terminal on the host. Run the block in bash or zsh, as root. Paste the whole block and press Enter once. When Enrollment key: appears, paste the key, and only the key, and press Enter. The key is not shown, and an empty line asks again. The key file is removed at the end, whether or not the join worked. If you stop the block with Ctrl-C, remove it with rm -f /run/secrets/sxaccess-key.

   You see: This device is now connected, then sxaccess info starting with Connected, and the host under Devices in site-muc. Repeat in Frankfurt with the key router-fra, the group site-fra and the hostname router-fra-office.

   shellCopy

   curl -fsSL https://pkgs.sxaccess.com/install.sh | sh{  install -d -m 700 /run/secrets  install -m 600 /dev/null /run/secrets/sxaccess-key  KEY=''  until [ -n "$KEY" ]; do printf 'Enrollment key: '; read -rs KEY || break; echo; done  [ -n "$KEY" ] && printf '%s' "$KEY" > /run/secrets/sxaccess-key && unset KEY &&    sxaccess start --enrollment-key-file /run/secrets/sxaccess-key --hostname router-muc-office &&    sxaccess info  rm -f /run/secrets/sxaccess-key}

3. 3

   Munich: publish the database, its rule and its routing device

   Networks › Internal networks › Add internal network: Network Name Munich office, then Add Network. Three forms follow:

   • Add Resource - Name Munich database, which sxaccess reach list shows. Address 10.20.0.15. Destination Groups: type muc-databases, press Enter. Then Add Resource. Publish the service, not the whole site.
   • Create access rule - the destination is already Munich database. Pick site-fra as the source, then TCP. Click the ports field, type 5432 and press Enter: the field shows 5432 instead of All. Then Create access rule. The source is Frankfurt's routing device, because that is the device Munich sees.
   • Add Routing Device - pick router-muc-office, then Continue. Leave Masquerade on, so the database needs no route back, and press Add Routing Device.

   You see: the Munich office row shows 1 resource, 1 device and site-fra. Frankfurt's routing device now reaches the database; its LAN needs steps 4 and 5.

4. 4

   Frankfurt: publish its own subnet

   Create Frankfurt office the same way. Its machines reach Munich only if their routing device serves their subnet with Masquerade on: it then gives their traffic its own tunnel address, which Munich admits.

   • Add Resource - Name Frankfurt LAN, Address 10.30.0.0/24, Destination Groups fra-lan.
   • Create access rule - source site-fra, any protocol. A resource is served only once a rule names it. This one opens nothing new: site-fra holds only the routing device, which is on that subnet already.
   • Add Routing Device - router-fra-office, Masquerade on.

   You see: sxaccess info on Frankfurt's routing device lists 10.30.0.0/24 under Networks. Publish every Frankfurt subnet whose machines should reach Munich.

5. 5

   Point Frankfurt's LAN at its routing device

   Frankfurt's machines still send Munich's addresses to their usual gateway. On that gateway, add a static route for exactly what Munich publishes, via the routing device's LAN address: here 10.20.0.15/32 via 10.30.0.2. Route nothing else; the routing device could only send it back.

   The routing device answers the machine directly, bypassing the gateway. If the gateway is a firewall that drops such connections, or you cannot change it, add the route on each machine instead, on Linux with the first block after these steps. Put it in the machine's network configuration too, so it survives a restart. Munich needs no route back.

   If ufw or Docker runs on Frankfurt's routing device, also allow forwarding from its LAN interface into the tunnel: both drop forwarded traffic by default. Run the second block after these steps there with ufw, the third with Docker; eth0 stands for the LAN interface.

   You see: a machine in Frankfurt reaches the database, as in Verify.

Verify

Troubleshooting

Advanced configuration

Related