mirror of
https://github.com/outbackdingo/firezone.git
synced 2026-01-27 10:18:54 +00:00
68ece0a940
This implements traffic filtering on the gateway. Filters are set on the
portal, per-resource, in an allow-list manner.
If no filters exist for a given resource all packets are allowed,
otherwise only packets that matches port/protocol for the filters are
allowed, otherwise they are dropped.
Filters can be either TCP, UDP or ICMP. For the first 2 multiple ports
can be given. Furthermore, multiple filters can exists for the same
resource.
To be able to add and remove filters with the same IP/CIDR we keep
around the whole list of filters for any given peer using an ID map and
recalculate the IP each time something is added is removed.
This allows us to remove filters and simply recalculate the allowlist
for each IP.
Furthermore, for any IP, all rules apply, meaning if there are multiple
IPs that apply for a resource all port/protocol combinations for that IP
will apply.
This works well right now for DNS resources, since access is requested
by DNS name, then the resource for that DNS name will arrive at the
gateway, and the port filtering will apply given that resource(and any
other resource with the same IP).
However, since the client has no idea of the filters, it can't request
the resource access based on the port/protocol combination and we are
still using the most specific("longest match") IP. This will mean that
for overlapping CIDR resources, only the rules for the most specific
will be used, even if the gateway supports applying them all, since it
will not have the other resources. This will be solved in #4789.
It can also lead to some weirdness, let's say that you have 10.0.0.0/24
-> TCP/80 and 10.0.0.0/16 -> TCP/443 for your user.
The user tries to access 10.0.0.1, and will then only be allowed port
80. At some point the user might access 10.1.0.1 and it will be allowed
port 443. But from that point on, the user will be allowed to access 80
and 443 in 10.0.0.1 because the rules correctly work on the gateway, the
problem is the client side. Again, #4789 will fix this.
Left for next PRs (in tentative order!):
- #4792
- #4789
Depends on: #4773.
Resolves #2030.
Resolves #4791.
---------
Co-authored-by: Jamil Bou Kheir <jamilbk@users.noreply.github.com>
gateway
This crate houses the Firezone gateway.
Building
You can build the gateway using: cargo build --release --bin firezone-gateway
You should then find a binary in target/release/firezone-gateway.
Running
The Firezone Gateway supports Linux only. To run the Gateway binary on your Linux host:
- Generate a new Gateway token from the "Gateways" section of the admin portal and save it in your secrets manager.
- Ensure the
FIREZONE_TOKEN=<gateway_token>environment variable is set securely in your Gateway's shell environment. The Gateway requires this variable at startup. - Set
FIREZONE_IDto a unique string to identify this gateway in the portal, e.g.export FIREZONE_ID=$(uuidgen). The Gateway requires this variable at startup. - Now, you can start the Gateway with:
firezone-gateway
If you're running as a non-root user, you'll need the CAP_NET_ADMIN capability
to open /dev/net/tun. You can add this to the gateway binary with:
sudo setcap 'cap_net_admin+eip' /path/to/firezone-gateway
Ports
The gateway requires no open ports. Connections automatically traverse NAT with STUN/TURN via the relay.