Skip to content

Implement passthrough egress policy - #2019

Merged
Lior Lieberman (LiorLieberman) merged 7 commits into
agent-substrate:mainfrom
yanavlasov:passthrough-policy
Oct 1, 2026
Merged

Lior Lieberman (LiorLieberman) merged 7 commits into
agent-substrate:mainfrom
yanavlasov:passthrough-policy

Conversation

@yanavlasov

@yanavlasov yanavlasov commented Sep 30, 2026 •

Copy link
Copy Markdown
Collaborator

Implement passthrough egress policy.

  • Tests pass
  • Appropriate changes to documentation are included in the PR

Signed-off-by: Yan Avlasov <[email protected]>

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

largely lgtm,

Is http a gap now?

Comment thread internal/egresspolicy/egresspolicy.go Resolved
@LiorLieberman

Copy link
Copy Markdown
Collaborator

Another thing I find, is that we have to re-resolve the sni we recieved for passthrough, we cant trust the actor resolved address. with this PR CONNECT leg sets the dialed IP:port as the passthrough destination, and this is taken from the ORIGINAL_DST. We have to instruct the gateway to not honor that ip the actor gave us and resolve the sni (if its a hostname)

@LiorLieberman

Copy link
Copy Markdown
Collaborator

Another thing I find, is that we have to re-resolve the sni we recieved for passthrough, we cant trust the actor resolved address. with this PR CONNECT leg sets the dialed IP:port as the passthrough destination, and this is taken from the ORIGINAL_DST. We have to instruct the gateway to not honor that ip the actor gave us and resolve the sni (if its a hostname)

maybe sni_dynamic_forward_proxy? to re-resolve never used that

Signed-off-by: Yan Avlasov <[email protected]>
Signed-off-by: Yan Avlasov <[email protected]>
@yanavlasov

Copy link
Copy Markdown
Collaborator Author

Another thing I find, is that we have to re-resolve the sni we recieved for passthrough, we cant trust the actor resolved address. with this PR CONNECT leg sets the dialed IP:port as the passthrough destination, and this is taken from the ORIGINAL_DST. We have to instruct the gateway to not honor that ip the actor gave us and resolve the sni (if its a hostname)

Sounds good. I propose doing it in a followup PR as it will require adding SNI based DFP into the filter chain and testing.

@yanavlasov

Copy link
Copy Markdown
Collaborator Author

Another thing I find, is that we have to re-resolve the sni we recieved for passthrough, we cant trust the actor resolved address. with this PR CONNECT leg sets the dialed IP:port as the passthrough destination, and this is taken from the ORIGINAL_DST. We have to instruct the gateway to not honor that ip the actor gave us and resolve the sni (if its a hostname)

maybe sni_dynamic_forward_proxy? to re-resolve never used that

Yes. Will will need this one. I suggest a follow up PR, so we do not hold up release.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

We are fixing the SNI re-resolve in a quick follow-up

Signed-off-by: Yan Avlasov <[email protected]>
Comment on lines +45 to +52
# Since this template is used to test both passthrough and MITM policies
# it will use both system and ATE bundles.
# For deployments with MITM only policies, add
#
# - name: SSL_CERT_DIR
# value: /run/ate
#
# to the "env" section to only use ATE bundle.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont think we need it

Suggested change
# Since this template is used to test both passthrough and MITM policies
# it will use both system and ATE bundles.
# For deployments with MITM only policies, add
#
# - name: SSL_CERT_DIR
# value: /run/ate
#
# to the "env" section to only use ATE bundle.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: you probably also need to do this fo microvm

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@LiorLieberman
Lior Lieberman (LiorLieberman) added this pull request to the merge queue Oct 1, 2026
Merged via the queue into agent-substrate:main with commit 6c75a41 Oct 1, 2026
10 checks passed
Scott Funkenhauser (sfunkenhauser) pushed a commit to sfunkenhauser/substrate that referenced this pull request Oct 1, 2026
The passthrough chain from agent-substrate#2019 dialed the ORIGINAL_DST filter state,
which the CONNECT leg filled with the address the actor connected to.
The SNI picked the chain, the actor's own resolution picked the
destination, so a passthrough rule for one name let an actor reach any
IP by claiming that name in the ClientHello.

We fix it by:

- The passthrough chain is now `sni_dynamic_forward_proxy` then
`tcp_proxy` to a new raw forward-proxy cluster,
`egress_forward_proxy_passthrough`, on the shared egress_dns_cache. The
gateway resolves the SNI itself and sends the bytes to it.

- The CONNECT leg answers the dialed port under
dev.ate.egress:dialed_port; the outer chain copies it into
envoy.upstream.dynamic_port, shared with the inner listener, which both
the SNI filter and the cluster read before their configured port.

> It's a good idea to open an issue first for discussion.

- [x] Tests pass
- [x] Appropriate changes to documentation are included in the PR
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/network kind/feature An enhancement / feature request or implementation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants