-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CONNECT-UDP in forwarding proxy mode resets stream and fails to send HTTP Datagrams #34836
Comments
/assign @jeongseokson |
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions. |
This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions. |
@RyanTheOptimist Hi Ryan, can you reopen it and mark it as no stale? I am currently working on this issue. |
/nostalebot |
@RyanTheOptimist while you're reopening this one, please also close #33775 - thanks! |
Done! |
Commit Message: When Envoy operates as a CONNECT-UDP forwarding proxy, it was resetting the upstream stream because it received HTTP Datagrams before receiving the SETTINGS frame. A new enum has been added in QUICHE to distinguish this case, so I added handling logic for this and made Envoy drop the datagrams instead of resetting the stream. Also, Envoy was dropping Datagrams because the default maximum packet length for QUIC connections in QUICHE is not large enough for tunneling use cases such as CONNECT-UDP. I added a new QUIC protocol option called `max_packet_length` to allow users to adjust the maximum packet length for upstream QUIC connections to fix this issue. Additional Description: Risk Level: Low, this change is only relevant if CONNECT-UDP is enabled with the forwarding mode. Testing: Added more unit tests. Docs Changes: Added the `max_packet_length` QUIC protocol option and its explanation. Release Notes: Added notes about fixing the CONNECT-UDP forwarding mode and adding the new QUIC protocol option. Platform Specific Features: N/A [Optional Fixes #Issue]: #34836 --------- Signed-off-by: Jeongseok Son <jeongseok.son@gmail.com>
Thanks for your patience, @Bfarkiani. We identified the issue thanks to your report. The fix has been merged into the main branch, so could you please try the forwarding mode again on your end after fetching the main branch? I was able to successfully make the two Envoy proxies (one for forwarding and the other for terminating) receive an HTTP/3 response from google.com using masque_client locally. Please let me know if you run into any problems. |
Dear @jeongseokson . Thank you for your help. I tested with the following configs: Client
Server:
Command: Client proxy printed:
Server proxy printed:
Command returned with no error and no data. I think it is the expected behavior? Thank you. |
The access log shows that it returned a 200 status code, so it seems to be working fine. You can pass the --stderrthreshold=0 flag to see the response printed out. Here's the command I used: $ ./masque_client --stderrthreshold=0 --disable_certificate_verification 127.0.0.1:10000 https://www.google.com/ |
Title: CONNECT-UDP in forwarding proxy mode resets stream and fails to send HTTP Datagrams
Description:
When Envoy is configured as a CONNECT-UDP forwarding proxy, where it forwards the requests to upstream and HTTP Datagrams without terminating HTTP, it fails to forward the HTTP Datagrams and resets the stream.
Repro steps:
Use the example config in configs/proxy_connect_udp_http3_downstream.yaml to run a CONNECT-UDP forwarding proxy, and send CONNECT-UDP request and subsequent HTTP Datagrams to it.
Admin and Stats Output:
See #33775
Config:
configs/proxy_connect_udp_http3_downstream.yaml
Logs:
See #33775
Call Stack:
See #33775
The text was updated successfully, but these errors were encountered: