I get "Socket error: [Errno 104] Connection reset by peer" on using my Px proxy

[halloleo]

On my RHEL system I have set up the proxy via

px --proxy=123.456.78.90:3129 r'--username=DOMAIN\user' --debug

(where 123.456.78.90:3129 stands for the outgoing NTLM proxy IP) but when I use this proxy on the same machine through a different command line with

curl -v -L -proxy 127.0.0.1:3128 https://httpbin.org/ip

the curl command fails and I see on the px command line:

Serving at 127.0.0.1:3128 proc MainProcess
MainProcess: MainThread: 1651633151: print_banner: proxy:server = 123.456.78.90:3129
MainProcess: MainThread: 1651633151: print_banner: proxy:pac = 
MainProcess: MainThread: 1651633151: print_banner: proxy:port = 3128
MainProcess: MainThread: 1651633151: print_banner: proxy:listen = 127.0.0.1
MainProcess: MainThread: 1651633151: print_banner: proxy:allow = *.*.*.*
MainProcess: MainThread: 1651633151: print_banner: proxy:gateway = 0
MainProcess: MainThread: 1651633151: print_banner: proxy:hostonly = 0
MainProcess: MainThread: 1651633151: print_banner: proxy:noproxy = 
MainProcess: MainThread: 1651633151: print_banner: proxy:useragent = 
MainProcess: MainThread: 1651633151: print_banner: proxy:username = DOMAIN\user
MainProcess: MainThread: 1651633151: print_banner: proxy:auth = 
MainProcess: MainThread: 1651633151: print_banner: settings:workers = 2
MainProcess: MainThread: 1651633151: print_banner: settings:threads = 5
MainProcess: MainThread: 1651633151: print_banner: settings:idle = 30
MainProcess: MainThread: 1651633151: print_banner: settings:socktimeout = 20.0
MainProcess: MainThread: 1651633151: print_banner: settings:proxyreload = 60
MainProcess: MainThread: 1651633151: print_banner: settings:foreground = 0
MainProcess: MainThread: 1651633151: print_banner: settings:log = 1
Process-1: MainThread: 1651633151: parse_noproxy: Noproxy += *.*.*.*
Serving at 127.0.0.1:3128 proc Process-1
Process-1: MainThread: 1651633151: print_banner: proxy:server = 123.456.78.90:3129
Process-1: MainThread: 1651633151: print_banner: proxy:pac = 
Process-1: MainThread: 1651633151: print_banner: proxy:port = 3128
Process-1: MainThread: 1651633151: print_banner: proxy:listen = 127.0.0.1
Process-1: MainThread: 1651633151: print_banner: proxy:allow = *.*.*.*
Process-1: MainThread: 1651633151: print_banner: proxy:gateway = 0
Process-1: MainThread: 1651633151: print_banner: proxy:hostonly = 0
Process-1: MainThread: 1651633151: print_banner: proxy:noproxy = 
Process-1: MainThread: 1651633151: print_banner: proxy:useragent = 
Process-1: MainThread: 1651633151: print_banner: proxy:username = DOMAIN\user
Process-1: MainThread: 1651633151: print_banner: proxy:auth = 
Process-1: MainThread: 1651633151: print_banner: settings:workers = 2
Process-1: MainThread: 1651633151: print_banner: settings:threads = 5
Process-1: MainThread: 1651633151: print_banner: settings:idle = 30
Process-1: MainThread: 1651633151: print_banner: settings:socktimeout = 20.0
Process-1: MainThread: 1651633151: print_banner: settings:proxyreload = 60
Process-1: MainThread: 1651633151: print_banner: settings:foreground = 0
Process-1: MainThread: 1651633151: print_banner: settings:log = 1
Process-1: MainThread: 1651633188: verify_request: Client address: 127.0.0.1
Process-1: Thread_0: 1651633188: do_CONNECT: Entering
Process-1: Thread_0: 1651633188: do_transaction: Entering
Process-1: Thread_0: 1651633188: get_netloc: netloc = ('httpbin.org', 443), path = /
Process-1: Thread_0: 1651633188: get_destination: Proxy = [('123.456.78.90', 3129)]
Process-1: Thread_0: 1651633188: do_socket_connect: New connection: ('123.456.78.90', 3129)
Process-1: Thread_0: 1651633188: do_proxy_type: Searching proxy type
Process-1: Thread_0: 1651633188: do_socket: Entering
Process-1: Thread_0: 1651633188: handle_one_request: Socket error: [Errno 104] Connection reset by peer

Does this mean my RHEL machine can't get to the NTLM proxy?

[genotrance]

If the connection is being dropped, it means the proxy rejected the connection. Either the IP is wrong or the port, or something else.

Are you able to get through the proxy using curl?

curl --proxy 123.456.78.90:3129 --proxy-user DOMAIN\user --proxy-pass PASS --proxy-anyauth -v https://httpbin.org/ip.

[halloleo]

Hey, Thanks your suggestion. I'm going down the curl path, but I don't expect you @genotrance to continue "holding my hand". The issue is getting off-topic for px, I guess...

That said, curl cannot connect either, but cntlm can! Very strange.

Here the details: When I use

curl -L --proxy 123.456.78.90:3129 --proxy-user DOMAIN\user  --proxy-anyauth -v https://httpbin.org/ip

(I had to remove --proxy-pass PASS because my version of curl doesn't recognise --proxy-pass) then I get:

curl: (56) Received HTTP code 407 from proxy after CONNECT

I understand this means that the issue is not caused by wrong credentials but by some auth-method mismatch.

Very strange, because on the same machine cntlm can do it!

[genotrance]

Probably because cntlm only supports ntlm so there’s no detection needed. Try curl with —proxy-ntlm instead of —proxy-anyauth. If that works then try px with —auth=NTLM.

If this works then it’s concerning since v0.7.0 is dealing with ntlm problems as well, see curl/curl#8778 (comment).

If your proxy does not like detection then I wonder how browsers deal with it.

[halloleo]

Great tip! curl -L --proxy 123... --proxy-user DOMAIN\\user --proxy-ntlm https://httpbin.org/ip works!

However, when I try the same in px with

px --auth=NTLM --proxy=123...  --username=CORP\\broleo --debug

and do curl -v -L --proxy 127.0.0.1:3128 https://httpbin.org/ip on the same machine, I see:

Process-1: MainThread: 1651803232: verify_request: Client address: 127.0.0.1    
Process-1: Thread_0: 1651803232: do_CONNECT: Entering                           
Process-1: Thread_0: 1651803232: do_transaction: Entering                       
Process-1: Thread_0: 1651803232: get_netloc: netloc = ('httpbin.org', 443), path
Process-1: Thread_0: 1651803232: get_destination: Proxy = [('192.168.80.81', 312
Process-1: Thread_0: 1651803232: do_socket_connect: New connection: ('192.168.80
Process-1: Thread_0: 1651803232: get_response_ntlm: ntlm-auth                   
Process-1: Thread_0: 1651803232: fwd_data: Reading response data                
Process-1: Thread_0: 1651803232: do_socket: Entering                            
Process-1: Thread_0: 1651803232: do_socket: CONNECT httpbin.org:443 HTTP/1.1    
Process-1: Thread_0: 1651803232: do_socket: Sending Host: httpbin.org:443       
Process-1: Thread_0: 1651803232: do_socket: Sending User-Agent: curl/7.29.0     
Process-1: Thread_0: 1651803232: do_socket: Sending Proxy-Connection: Keep-Alive
Process-1: Thread_0: 1651803232: do_socket: Sending extra Proxy-Authorization: s
Process-1: Thread_0: 1651803232: do_socket: Sending extra b'Proxy-Connection: Ke
Process-1: Thread_0: 1651803232: do_socket: Reading response code               
Process-1: Thread_0: 1651803232: do_socket: Response code: 407 True             
Process-1: Thread_0: 1651803232: do_socket: Reading response headers            
Process-1: Thread_0: 1651803232: do_socket: Received Expires: 0                 
Process-1: Thread_0: 1651803232: do_socket: Received Server: WebMarshal Proxy   
Process-1: Thread_0: 1651803232: do_socket: Received Cache-Control: no-cache    
Process-1: Thread_0: 1651803232: do_socket: Received Proxy-Connection: close    
Process-1: Thread_0: 1651803232: do_socket: Received Via: 1.1 WEBMARSHAL        
Process-1: Thread_0: 1651803232: do_socket: Received Content-Length: 2370       
Process-1: Thread_0: 1651803232: do_socket: Received Content-Type: text/html; ch
Process-1: Thread_0: 1651803232: do_socket: Received Proxy-Authenticate: sanitiz
Process-1: Thread_0: 1651803232: do_socket: Received X-WebMarshal-RequestID: 62B
Process-1: Thread_0: 1651803232: do_transaction: Auth required                  
Process-1: Thread_0: 1651803232: do_transaction: Didn't get challenge, auth didn
Process-1: Thread_0: 1651803232: do_CONNECT: Error 407                          
Process-1: Thread_0: 1651803232: fwd_resp: Entering                             
Process-1: Thread_0: 1651803232: log_message: "CONNECT httpbin.org:443 HTTP/1.1"
Process-1: Thread_0: 1651803232: fwd_resp: Returning Expires: 0                 
Process-1: Thread_0: 1651803232: fwd_resp: Returning Server: WebMarshal Proxy   
Process-1: Thread_0: 1651803232: fwd_resp: Returning Cache-Control: no-cache    
Process-1: Thread_0: 1651803232: fwd_resp: Returning Proxy-Connection: close    
Process-1: Thread_0: 1651803232: fwd_resp: Returning Via: 1.1 WEBMARSHAL        
Process-1: Thread_0: 1651803232: fwd_resp: Returning Content-Length: 2370       
Process-1: Thread_0: 1651803232: fwd_resp: Returning Content-Type: text/html; ch
Process-1: Thread_0: 1651803232: fwd_resp: Returning Proxy-Authenticate: Basic r
Process-1: Thread_0: 1651803232: fwd_resp: Returning X-WebMarshal-RequestID: 62B
Process-1: Thread_0: 1651803232: fwd_data: Reading response data                
Process-1: Thread_0: 1651803232: fwd_data: Content length 2370                  
Process-1: Thread_0: 1651803232: fwd_data: Close proxy connection per header    
Process-1: Thread_0: 1651803232: fwd_resp: Done                                 
Process-1: Thread_0: 1651803232: do_CONNECT: 0 bytes read, 0 bytes written      
Process-1: Thread_0: 1651803232: do_CONNECT: Done                               

(Sorry, all lines are cut at 80 characters due to terminal issues.)

[genotrance]

There should be a log file in the px directory that contains the full output.

What's the output for curl -v? Will be interesting to see what headers it is sending and receiving back.

More painful but the alternative would be to know what header the upstream proxy returned for Proxy-Authenticate. It is being sanitized for privacy reasons here:

px/px.py

Lines 611 to 614 in 6b0a42b

	if name.lower() != "proxy-authenticate":
	dprint("Received %s: %s" % (name, value))
	else:
	dprint("Received %s: sanitized (%d)" % (name, len(value)))

Doesn't help since I don't see what the actual response was:

Process-1: Thread_0: 1651803232: do_socket: Received Proxy-Authenticate: sanitiz

If you can remove that if statement and always print output: dprint("Received %s: %s" % (name, value)) then we can see why px feels it wasn't challenged.

px/px.py

Line 726 in 6b0a42b

if (header[0].lower() == "proxy-authenticate" and

[halloleo]

@genotrance, I am now on holidays. I'll have a look at the issue in 4 weeks time. Sorry for this. I will certainly touch base with you then.

Thanks again for all the patient hand-holding. I'm sure we will make it work!

[halloleo]

Writing up the finally result of the other answer trail here, so that the most important part is visible here in the accepted answer:

On RHEL 7 I had to use:

1. the —auth=NTLM option
2. the keyrings.alt package to store the password.

With these settings it works now!

Thanks @genotrance for all tips & suggestions!