search

erebe / wstunnel

Tunnel all your traffic over Websocket or HTTP2 - Bypass firewalls/DPI - Static binary available
Other
3.22k stars 290 forks source link

TimeZone Problem with tls #184

Closed keke1229488344 closed 6 months ago

keke1229488344 commented 6 months ago

The wstunnel server use timezone GMT+8. The wstunnel client run in the docker base centos7, and the Docker server timezone is GMT+0. When I try to connect to the wstunnel server, it echo:

2023-11-09T02:52:29.493229Z  INFO tunnel{peer="[::ffff:xxx.112.87.xxx]:39215"}: wstunnel::tunnel::server: Doing TLS handshake
2023-11-09T02:52:29.823969Z ERROR tunnel{peer="[::ffff:xxx.112.87.xxx]:39215"}: wstunnel::tunnel::server: error while accepting TLS connection tls handshake eof

So firstly I try to modify the timezone in the centos docker, after I modify /etc/timezone and /etc/localtime, and when I typing date, it successfully work with GMT+8. However, when I run the wstunnel client again, the logs shows that it still use GMT+0, and cannot connect to the server with the same error.

erebe commented 6 months ago

Would you mind running the client with the env variable RUST_LOG=trace set and sending me back the log.

keke1229488344 commented 6 months ago

sure, will update it later

keke1229488344 commented 6 months ago

It seems that the issue is not related to different time zones (although the displayed time zone is not correct) However, I am still unable to successfully connect to the wstunnel server at my company (even though I was able to connect to the server successfully from my home...)

Below are the logs from the client and server sides, obtained with trace enabled, using both the ws and wss modes. (Specially, when using the ws mode, the server side did not generate any log outputs.)

Caused by: Invalid status code 2023-11-10T08:12:57.849839Z TRACE hyper::proto::h1::dispatch: body receiver dropped before eof, draining or closing 2023-11-10T08:12:57.849866Z TRACE hyper::proto::h1::decode: decode; state=Eof(false) 2023-11-10T08:12:57.850122Z TRACE hyper::proto::h1::conn: State::close_read() 2023-11-10T08:12:57.850203Z TRACE hyper::proto::h1::conn: State::close() 2023-11-10T08:12:57.850289Z TRACE hyper::proto::h1::conn: flushed({role=client}): State { reading: Closed, writing: Closed, keep_alive: Disabled } 2023-11-10T08:12:57.850367Z TRACE hyper::proto::h1::conn: shut down IO complete

- using ws mode : server log

no log.... seems that it don't create a connection to the server...

- using wss mode : client log

/ # ./wstunnel client -L tcp://0.0.0.0:9997:127.0.0.1:6116 -p http://123:abc@proxy.example.com:8080 wss://wstunnel.example.com:7443 2023-11-10T08:18:42.095940Z INFO wstunnel::tcp: Starting TCP server listening cnx on 0.0.0.0:9997
2023-11-10T08:18:45.168939Z INFO wstunnel::tcp: Opening TCP connection to proxy.example.com:8080
2023-11-10T08:18:45.292134Z DEBUG wstunnel::tcp: connecting to 130.xx.xx.65:8080 2023-11-10T08:18:45.299844Z INFO wstunnel::tcp: Connected to http proxy proxy.example.com:8080
2023-11-10T08:18:45.312536Z INFO wstunnel::tcp: http proxy connected to remote host wstunnel.example.com:7443
2023-11-10T08:18:45.312593Z INFO wstunnel::tls: Doing TLS handshake using sni DnsName("wstunnel.example.com") with the server wstunnel.example.com:7443 2023-11-10T08:18:45.314596Z DEBUG rustls::client::hs: No cached session for DnsName("wstunnel.example.com")
2023-11-10T08:18:45.314681Z DEBUG rustls::client::hs: Not resuming any session
2023-11-10T08:18:45.314713Z TRACE rustls::client::hs: Sending ClientHello Message { version: TLSv1_0, payload: Handshake { parsed: HandshakeMessagePayload { typ: ClientHello, payload: ClientHello( ClientHelloPayload { client_version: TLSv1_2, random: 2ba9781717ef91e8f7860bce98649f31b68ee17a6b152d0728e53e72b4d87428, session_id: 8d218f329e64dae9b20f75b0142f103a0d92347f7ecdc63278cc3f69036dad56, cipher_suites: [ TLS13_AES_256_GCM_SHA384, TLS13_AES_128_GCM_SHA256, TLS13_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_EMPTY_RENEGOTIATION_INFO_SCSV, ], compression_methods: [ Null, ], extensions: [ SupportedVersions( [ TLSv1_3, TLSv1_2, ], ), ECPointFormats( [ Uncompressed, ], ), NamedGroups( [ X25519, secp256r1, secp384r1, ], ), SignatureAlgorithms( [ ECDSA_NISTP384_SHA384, ECDSA_NISTP256_SHA256, ED25519, RSA_PSS_SHA512, RSA_PSS_SHA384, RSA_PSS_SHA256, RSA_PKCS1_SHA512, RSA_PKCS1_SHA384, RSA_PKCS1_SHA256, ], ), ExtendedMasterSecretRequest, CertificateStatusRequest( OCSP( OCSPCertificateStatusRequest { responder_ids: [], extensions: , }, ), ), ServerName( [ ServerName { typ: HostName, payload: HostName( DnsName( "wstunnel.example.com", ), ), }, ], ), SignedCertificateTimestampRequest, KeyShare( [ KeyShareEntry { group: X25519, payload: 924f77254efbfc864af374a83feacdca9966390f63c8225fab8e81bf97210b5e, }, ], ), PresharedKeyModes( [ PSK_DHE_KE, ], ), Protocols( [ ProtocolName( 687474702f312e31, ), ], ), SessionTicket( Request, ), ], }, ), }, encoded: 0100010203032ba9781717ef91e8f7860bce98649f31b68ee17a6b152d0728e53e72b4d87428208d218f329e64dae9b20f75b0142f103a0d92347f7ecdc63278cc3f69036dad560014130213011303c02cc02bcca9c030c02fcca800ff010000a5002b00050403040303000b00020100000a00080006001d00170018000d00140012050304030807080608050804060105010401001700000005000501000000000000001a00180000156e7073312e68686862632e636c6f75646e732e706800120000003300260024001d0020924f77254efbfc864af374a83feacdca9966390f63c8225fab8e81bf97210b5e002d000201010010000b000908687474702f312e3100230000, }, }
...

- using wss mode : server log

2023-11-10T08:18:36.396254Z INFO wstunnel: WsServerConfig { socket_so_mark: None, bind: [::]:7443, restrict_to: None, websocket_ping_frequency: None, timeout_connect: 10s, websocket_mask_frame: false, tls: true } 2023-11-10T08:18:36.396298Z INFO wstunnel::tunnel::server: Starting wstunnel server listening on [::]:7443 2023-11-10T08:18:45.399360Z INFO wstunnel::tunnel::server: Accepting connection 2023-11-10T08:18:45.400558Z INFO tunnel{peer="[::ffff:203.xxx.xx.1]:8157"}: wstunnel::tunnel::server: Doing TLS handshake 2023-11-10T08:18:45.402993Z TRACE tunnel{peer="[::ffff:203.xxx.xx.1]:8157"}: rustls::server::hs: we got a clienthello ClientHelloPayload { client_version: TLSv1_2, random: 2ba9781717ef91e8f7860bce98649f31b68ee17a6b152d0728e53e72b4d87428, session_id: , cipher_suites: [TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_EMPTY_RENEGOTIATION_INFO_SCSV], compression_methods: [Null], extensions: [ECPointFormats([Uncompressed]), NamedGroups([secp256r1, secp384r1]), SignatureAlgorithms([ECDSA_NISTP384_SHA384, ECDSA_NISTP256_SHA256, RSA_PKCS1_SHA512, RSA_PKCS1_SHA384, RSA_PKCS1_SHA256]), ServerName([ServerName { typ: HostName, payload: HostName(DnsName("wstunnel.example.com")) }]), Protocols([ProtocolName(687474702f312e31)])] }
2023-11-10T08:18:45.403052Z TRACE tunnel{peer="[::ffff:203.xxx.xx.1]:8157"}: rustls::server::server_conn: sni Some(DnsName("wstunnel.example.com"))
2023-11-10T08:18:45.403060Z TRACE tunnel{peer="[::ffff:203.xxx.xx.1]:8157"}: rustls::server::server_conn: sig schemes [ECDSA_NISTP384_SHA384, ECDSA_NISTP256_SHA256, RSA_PKCS1_SHA512, RSA_PKCS1_SHA384, RSA_PKCS1_SHA256]
2023-11-10T08:18:45.403067Z TRACE tunnel{peer="[::ffff:203.xxx.xx.1]:8157"}: rustls::server::server_conn: alpn protocols Some([ProtocolName(687474702f312e31)])
2023-11-10T08:18:45.403073Z TRACE tunnel{peer="[::ffff:203.xxx.xx.1]:8157"}: rustls::server::server_conn: cipher suites [TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
2023-11-10T08:18:45.403083Z DEBUG tunnel{peer="[::ffff:203.xxx.xx.1]:8157"}: rustls::server::hs: decided upon suite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
2023-11-10T08:18:45.403110Z TRACE tunnel{peer="[::ffff:203.xxx.xx.1]:8157"}: rustls::server::tls12::client_hello: namedgroups [secp256r1, secp384r1]
2023-11-10T08:18:45.403117Z TRACE tunnel{peer="[::ffff:203.xxx.xx.1]:8157"}: rustls::server::tls12::client_hello: ecpoints [Uncompressed]
2023-11-10T08:18:45.403203Z DEBUG tunnel{peer="[::ffff:203.xxx.xx.1]:8157"}: rustls::server::hs: Chosen ALPN protocol [104, 116, 116, 112, 47, 49, 46, 49]
2023-11-10T08:18:45.403221Z TRACE tunnel{peer="[::ffff:203.xxx.xx.1]:8157"}: rustls::server::tls12::client_hello: sending server hello Message { version: TLSv1_2, payload: Handshake { parsed: HandshakeMessagePayload { typ: ServerHello, payload: ServerHello(ServerHelloPayload { legacy_version: TLSv1_2, random: a443c9286e8393e3726a5caee4a357cc661b1deb116a9b74444f574e47524401, session_id: 1e3b00dc3a243394f253f26384a58abd742e871dfa5d00ca9921791d09205e85, cipher_suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, compression_method: Null, extensions: [Protocols([ProtocolName(687474702f312e31)]), ServerNameAck, RenegotiationInfo()] }) }, encoded: 020000600303a443c9286e8393e3726a5caee4a357cc661b1deb116a9b74444f574e47524401201e3b00dc3a243394f253f26384a58abd742e871dfa5d00ca9921791d09205e85c0300000180010000b000908687474702f312e3100000000ff01000100 } }
2023-11-10T08:18:46.262260Z ERROR tunnel{peer="[::ffff:203.xxx.xx.1]:8157"}: wstunnel::tunnel::server: error while accepting TLS connection tls handshake eof 2023-11-10T08:18:46.776262Z INFO wstunnel::tunnel::server: Accepting connection 2023-11-10T08:18:46.776325Z INFO tunnel{peer="[::ffff:203.xxx.xx.1]:9530"}: wstunnel::tunnel::server: Doing TLS handshake 2023-11-10T08:18:46.776784Z TRACE tunnel{peer="[::ffff:203.xxx.xx.1]:9530"}: rustls::server::hs: we got a clienthello ClientHelloPayload { client_version: TLSv1_2, random: 2f6a7f2d2759bf33ed34238986cb8b954fd7c446838196274aa8c442f1a99434, session_id: , cipher_suites: [TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_EMPTY_RENEGOTIATION_INFO_SCSV], compression_methods: [Null], extensions: [ECPointFormats([Uncompressed]), NamedGroups([secp256r1, secp384r1]), SignatureAlgorithms([ECDSA_NISTP384_SHA384, ECDSA_NISTP256_SHA256, RSA_PKCS1_SHA512, RSA_PKCS1_SHA384, RSA_PKCS1_SHA256]), ServerName([ServerName { typ: HostName, payload: HostName(DnsName("wstunnel.example.com")) }]), Protocols([ProtocolName(687474702f312e31)])] }
2023-11-10T08:18:46.776829Z TRACE tunnel{peer="[::ffff:203.xxx.xx.1]:9530"}: rustls::server::server_conn: sni Some(DnsName("wstunnel.example.com"))
2023-11-10T08:18:46.776836Z TRACE tunnel{peer="[::ffff:203.xxx.xx.1]:9530"}: rustls::server::server_conn: sig schemes [ECDSA_NISTP384_SHA384, ECDSA_NISTP256_SHA256, RSA_PKCS1_SHA512, RSA_PKCS1_SHA384, RSA_PKCS1_SHA256]
2023-11-10T08:18:46.776843Z TRACE tunnel{peer="[::ffff:203.xxx.xx.1]:9530"}: rustls::server::server_conn: alpn protocols Some([ProtocolName(687474702f312e31)])
2023-11-10T08:18:46.776849Z TRACE tunnel{peer="[::ffff:203.xxx.xx.1]:9530"}: rustls::server::server_conn: cipher suites [TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
2023-11-10T08:18:46.776857Z DEBUG tunnel{peer="[::ffff:203.xxx.xx.1]:9530"}: rustls::server::hs: decided upon suite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
2023-11-10T08:18:46.776872Z TRACE tunnel{peer="[::ffff:203.xxx.xx.1]:9530"}: rustls::server::tls12::client_hello: namedgroups [secp256r1, secp384r1]
2023-11-10T08:18:46.776878Z TRACE tunnel{peer="[::ffff:203.xxx.xx.1]:9530"}: rustls::server::tls12::client_hello: ecpoints [Uncompressed]
2023-11-10T08:18:46.776890Z DEBUG tunnel{peer="[::ffff:203.xxx.xx.1]:9530"}: rustls::server::hs: Chosen ALPN protocol [104, 116, 116, 112, 47, 49, 46, 49]
2023-11-10T08:18:46.776901Z TRACE tunnel{peer="[::ffff:203.xxx.xx.1]:9530"}: rustls::server::tls12::client_hello: sending server hello Message { version: TLSv1_2, payload: Handshake { parsed: HandshakeMessagePayload { typ: ServerHello, payload: ServerHello(ServerHelloPayload { legacy_version: TLSv1_2, random: b950910dcf35629cc625df7b6b4046d7ebef817a05442372444f574e47524401, session_id: b7fc982cecff5b9f3de4963a01e4a4e9f44d8966014e7fe18d7e8c82336c7b29, cipher_suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, compression_method: Null, extensions: [Protocols([ProtocolName(687474702f312e31)]), ServerNameAck, RenegotiationInfo()] }) }, encoded: 020000600303b950910dcf35629cc625df7b6b4046d7ebef817a05442372444f574e4752440120b7fc982cecff5b9f3de4963a01e4a4e9f44d8966014e7fe18d7e8c82336c7b29c0300000180010000b000908687474702f312e3100000000ff01000100 } }
2023-11-10T08:18:47.183649Z ERROR tunnel{peer="[::ffff:203.xxx.xx.1]:9530"}: wstunnel::tunnel::server: error while accepting TLS connection tls handshake eof 2023-11-10T08:18:48.153604Z INFO wstunnel::tunnel::server: Accepting connection ...

yu-james commented 6 months ago

Smells like something to do with your proxy. Did you say you got it working in some scenario?

keke1229488344 commented 6 months ago

Yes, I have successfully used the software sockscap64 to connect to the RDP service through this httpproxy. And it is also work when I connect to remote SSH service by setting this httpproxy in putty.

However, when I switched to wstunnel and mapped the remote RDP service to 127.0.0.1:9997, it didn't work.

And, it's worth mentioning that my httpproxy restricts access to certain domains (but the domain i used in the above log is whitelisted), so I am thinking that if wstunnel may lose some domain information when handling them : (

keke1229488344 commented 6 months ago

Besides, in the log I can see that my wstunnel server successfully received the connection requested by wstunnel client via httpproxy (in wss mode), it seems that my httpproxy works in some ways... but I'm confused as to why they disconnected before completing the connection.

erebe commented 6 months ago

Like that, it is kinds of hard to tell. I agree with @yu-james , your issue seems to come down to the proxy. The client propose tlsv1.2 & tlsv1.3, but the server receives only tls1.2. So something is the middle is stripping the tls request. After that, the handshake seems to go on, but the proxy after the server TLS response close the connection (the eof). So somehow, the proxy does not like the response and is force closing the connection.

Do you have any verbose log of the proxy, to understand what it does not like ?

P.s: I am going offline for vacation, I am coming back end of november.

keke1229488344 commented 6 months ago

Thanks for your reply. Unfortunately, I cannot access the logs of the httpproxy...

So.. may this issue is related to the self signed certificate?

and I'm still confused about why server do not receive any logs when using ws mode...

erebe commented 6 months ago

Same, would say because of the proxy if you don't see any log server side. The "server" which is not the server as you don't see anything on your end, return an error HTTP response when doing the websocket HTTP upgrade connection.

If you don't mind, would you try taking a network capture with TCP dump, and sending me the capture.pcap file ? Do the capture on the client without TLS (only ws://)

sudo tcpdump -w capture.pcap -i your_network_interface -nn -s0 -v port 7777

to get your network interface, you can do ip a or ip route and check the interface of the default gateway.

yu-james commented 6 months ago

The fact that wss hit the server but ws didn't, suggests it might be some headers exposed it's intention so got blocked by your corporate proxy. Also did you try mask frame?

Otherwise like mentioned above, tcp dump is the best way. But I would suggest dump the traffic between client and proxy.

keke1229488344 commented 6 months ago

capture.zip updated.

yu-james commented 6 months ago

Weird. Server says 404?

Did you by any chance use upgrade-prefix, upgrade-credential or anything?

Are server and client at the same version?

keke1229488344 commented 6 months ago

yep, server and client use the same version v7.9.2. and, I am not using upgrade-prefix upgrade-credential, the running command on my server simply is ./wstunnel server ws://[::]:7443

Besides, I saw in the capture.pcap that the port (7443) was lost for the second connection, could this be the cause of the 404?

image

erebe commented 6 months ago

Hi back,

I got a chance to take a look at the pcap, and from what I understand you have a nginx between your proxy and the server that reject the request with 404 not found.

[client] ---> [proxy] ---> [nginx reverse proxy] --> [server]

The proxy is correctly forwarding/allowing the request, just the configured nginx does not found it.

As you mention, it can be due to the lack of port in the Host header. Would you mind starting the client with the -H option:

wstunnel client -H "host: cccat.hhhbc.cloudns.ph:7443" ....

And let me know the outcome ? This option should override the Host header the client send to the server

keke1229488344 commented 6 months ago

Hi, yep, my server does have nginx installed, but it's only used for web purposes, and it only listens on ports 80 and 443.

as you say, I think it's possible that the host is missing the port, causing the wstunnel connection to go through ports 80/443 and mistakenly passing through nginx.

wonderful suggestion! I will try it tomorrow when I go back to my company.

keke1229488344 commented 6 months ago

Good news! it works well after I added the -H option, thank you for your help!

bytejedi commented 6 months ago

Hi back,

I got a chance to take a look at the pcap, and from what I understand you have a nginx between your proxy and the server that reject the request with 404 not found.

[client] ---> [proxy] ---> [nginx reverse proxy] --> [server]

The proxy is correctly forwarding/allowing the request, just the configured nginx does not found it.

As you mention, it can be due to the lack of port in the Host header. Would you mind starting the client with the -H option:

wstunnel client -H "host: cccat.hhhbc.cloudns.ph:7443" ....

And let me know the outcome ? This option should override the Host header the client send to the server

Yes, this is the point. Nginx set proxy_set_header Host $http_host; so the wstunnel client should set Host Header too.

keke1229488344 commented 6 months ago

Hi back, I got a chance to take a look at the pcap, and from what I understand you have a nginx between your proxy and the server that reject the request with 404 not found. [client] ---> [proxy] ---> [nginx reverse proxy] --> [server] The proxy is correctly forwarding/allowing the request, just the configured nginx does not found it. As you mention, it can be due to the lack of port in the Host header. Would you mind starting the client with the -H option:

wstunnel client -H "host: cccat.hhhbc.cloudns.ph:7443" ....

And let me know the outcome ? This option should override the Host header the client send to the server

Yes, this is the point. Nginx set proxy_set_header Host $http_host; so the wstunnel client should set Host Header too.

Yep.. But I find it very strange, because this issue does not occur when running wstunnel client on my home computer. . . I think the connection shouldn't pass through the nginx, it should directly connect to the dest port.

erebe commented 6 months ago

Thanks for letting me know it works. I will try to make the fix in the Incoming day.

Regarding that it is strange your nginx catch it, i find it too. If your nginx is listening only on 80 & 443, it should not intercept the connection on 7443.

From the pcap, the proxy is correctly connecting to port 7443, so there is no reason your nginx on 80/443 catch it. Maybe something missconfigured ?

Anyway, i am going to fix for the host header missing the port when it is not standard.

bytejedi commented 6 months ago

Thanks for letting me know it works. I will try to make the fix in the Incoming day.

Regarding that it is strange your nginx catch it, i find it too. If your nginx is listening only on 80 & 443, it should not intercept the connection on 7443.

From the pcap, the proxy is correctly connecting to port 7443, so there is no reason your nginx on 80/443 catch it. Maybe something missconfigured ?

Anyway, i am going to fix for the host header missing the port when it is not standard.

In my scenario, My nginx is listening only on 80 & 443, wstunnel client just works with set --http-headers "Host: xxx.com" without port. I think it's not a bug.

My configuration works fine. ⬇️

wstunnel client -L udp://127.0.0.1:49818:127.0.0.1:49818?timeout_sec=0 wss://1.2.3.4:443 --tls-verify-certificate --tls-sni-override xxx.com --http-upgrade-path-prefix somepathprefix --http-headers "Host: xxx.com" --websocket-ping-frequency-sec 15

wstunnel server ws://127.0.0.1:12345 --restrict-to 127.0.0.1:49818

erebe commented 6 months ago

Thanks for letting me know it works. I will try to make the fix in the Incoming day. Regarding that it is strange your nginx catch it, i find it too. If your nginx is listening only on 80 & 443, it should not intercept the connection on 7443. From the pcap, the proxy is correctly connecting to port 7443, so there is no reason your nginx on 80/443 catch it. Maybe something missconfigured ? Anyway, i am going to fix for the host header missing the port when it is not standard.

In my scenario, My nginx is listening only on 80 & 443, wstunnel client just works with set --http-headers "Host: xxx.com" without port. I think it's not a bug.

My configuration works fine. ⬇️

wstunnel client -L udp://127.0.0.1:49818:127.0.0.1:49818?timeout_sec=0 wss://1.2.3.4:443 --tls-verify-certificate --tls-sni-override xxx.com --http-upgrade-path-prefix somepathprefix --http-headers "Host: xxx.com" --websocket-ping-frequency-sec 15

wstunnel server ws://127.0.0.1:12345 --restrict-to 127.0.0.1:49818

The port is only mandatory when it is not the default (i.e: 80 / 443), so in this case it is a bug as his port is 7443 and should be explicit in the header. For reference https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Host

@keke1229488344 I made a new release https://github.com/erebe/wstunnel/releases/tag/v7.9.3 that should fix the issue (no need to override the host with -H)

keke1229488344 commented 6 months ago

Thanks for letting me know it works. I will try to make the fix in the Incoming day. Regarding that it is strange your nginx catch it, i find it too. If your nginx is listening only on 80 & 443, it should not intercept the connection on 7443. From the pcap, the proxy is correctly connecting to port 7443, so there is no reason your nginx on 80/443 catch it. Maybe something missconfigured ? Anyway, i am going to fix for the host header missing the port when it is not standard.

In my scenario, My nginx is listening only on 80 & 443, wstunnel client just works with set --http-headers "Host: xxx.com" without port. I think it's not a bug. My configuration works fine. ⬇️ wstunnel client -L udp://127.0.0.1:49818:127.0.0.1:49818?timeout_sec=0 wss://1.2.3.4:443 --tls-verify-certificate --tls-sni-override xxx.com --http-upgrade-path-prefix somepathprefix --http-headers "Host: xxx.com" --websocket-ping-frequency-sec 15 wstunnel server ws://127.0.0.1:12345 --restrict-to 127.0.0.1:49818

The port is only mandatory when it is not the default (i.e: 80 / 443), so in this case it is a bug as his port is 7443 and should be explicit in the header. For reference https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Host

@keke1229488344 I made a new release https://github.com/erebe/wstunnel/releases/tag/v7.9.3 that should fix the issue (no need to override the host with -H)

Thanks for your update. I have tested v7.9.3, it now works well without -H.

As there are no issues encountered while running the wstunnel now, I will close this issue. Thank you for your help.