#955 adds initial integration with OPTE, which provides the virtual networks over which guests communicate. That pull request implements the core integration, but isn't fully complete end-to-end. In particular, guests in the same VPC Subnet still can't directly communicate with one another, since the default firewall disposition in OPTE is to block all such traffic. Developers can get around this by adding firewall rules to OPTE with a command line invocation like:
bnaecker@feldspar : ~/omicron $ pfexec /opt/oxide/opte/bin/opteadm add-fw-rule -p opte0 --action allow --dir in --hosts subnet=172.30.0.0/22 --ports any --priority 10 --protocol tcp
where opte0 is the guest OPTE port object, and the subnet matches whatever the guest was created with.
This issue tracks providing the current set of firewall rules that apply to a guest in the actual instance-creation request sent to the sled agent. This is distinct from the work required for distributing a new set of firewall rules to the right sleds when the rules are modified via the public API, it's only the initial rules that apply at creation time.
#955 adds initial integration with OPTE, which provides the virtual networks over which guests communicate. That pull request implements the core integration, but isn't fully complete end-to-end. In particular, guests in the same VPC Subnet still can't directly communicate with one another, since the default firewall disposition in OPTE is to block all such traffic. Developers can get around this by adding firewall rules to OPTE with a command line invocation like:
where
opte0is the guest OPTE port object, and the subnet matches whatever the guest was created with.This issue tracks providing the current set of firewall rules that apply to a guest in the actual instance-creation request sent to the sled agent. This is distinct from the work required for distributing a new set of firewall rules to the right sleds when the rules are modified via the public API, it's only the initial rules that apply at creation time.