MPS - failed to read tcp forward request

[EBara5]

Hey everyone,

We're trying to setup an AMT remote solution. We're successfully getting the connection from the AMT device, passing the certificate check but then we're stuck.

The MPS server gives us the following error: "AMT_Tunnel_Supplier: failed to read tcp forward request".

We're wondering if anyone here can give us a direction to were the problem comes from.

The full MPS log is attached.

[Anonymous · Accepted solution]

Hello Evgeny,

I recommend you review the excellent document "Intel vPro Technology Use Case Reference Design - CIRA Ref Architecture" which can be found here: https://downloadcenter.intel.com/download/22694 Intel® Download Center

Check stunnel, mps and apache config files according to this guide and the samples provided. From an MPS perspective it looks like the AMT Port Forwarding (APF) authorisation service (mailto:auth@amt.intel.com auth@amt.intel.com) and Intel AMT port forwarding requests (mailto:pfwd@amt.intel.com pfwd@amt.intel.com) are successful but if Stunnel log output doesn't look similar to section 9 "Troubleshooting" in the above document then you likely have issues with your SSL certificate and setting up the secure tunnel, which APF relies upon.

Follow the guide to the letter and you will be successful! You may also find additional detail in the latest https://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide/ Intel® AMT SDK Documentation useful.

Regards

- Martin.

[EBara5]

Hi Martin,

First of all, thank for the answer. You gave a really great reference, it's a shame I couldn't find it until now

Now, regarding the certificate. As I've told, I'm pretty sure we pass the authentication. We get the following log in the stunnel:

2015.05.06 11:09:37 LOG7[main]: Service [psudo-tcp] accepted (FD=548) from 84.228.118.88:16994

2015.05.06 11:09:37 LOG7[main]: Creating a new thread

2015.05.06 11:09:37 LOG7[main]: New thread created

2015.05.06 11:09:37 LOG7[13]: Service [psudo-tcp] started

2015.05.06 11:09:37 LOG5[13]: Service [psudo-tcp] accepted connection from 84.228.118.88:16994

2015.05.06 11:09:37 LOG7[13]: SSL state (accept): before/accept initialization

2015.05.06 11:09:37 LOG7[13]: SNI: no virtual services defined

2015.05.06 11:09:37 LOG7[13]: SSL state (accept): SSLv3 read client hello A

2015.05.06 11:09:37 LOG7[13]: SSL state (accept): SSLv3 write server hello A

2015.05.06 11:09:37 LOG7[13]: SSL state (accept): SSLv3 write certificate A

2015.05.06 11:09:37 LOG7[13]: SSL state (accept): SSLv3 write certificate request A

2015.05.06 11:09:37 LOG7[13]: SSL state (accept): SSLv3 flush data

2015.05.06 11:09:37 LOG7[13]: SSL state (accept): SSLv3 read client certificate A

2015.05.06 11:09:37 LOG7[13]: SSL state (accept): SSLv3 read client key exchange A

2015.05.06 11:09:37 LOG7[13]: SSL state (accept): SSLv3 read finished A

2015.05.06 11:09:37 LOG7[13]: SSL state (accept): SSLv3 write change cipher spec A

2015.05.06 11:09:37 LOG7[13]: SSL state (accept): SSLv3 write finished A

2015.05.06 11:09:37 LOG7[13]: SSL state (accept): SSLv3 flush data

2015.05.06 11:09:37 LOG7[13]: 14 server accept(s) requested

2015.05.06 11:09:37 LOG7[13]: 14 server accept(s) succeeded

2015.05.06 11:09:37 LOG7[13]: 0 server renegotiation(s) requested

2015.05.06 11:09:37 LOG7[13]: 0 session reuse(s)

2015.05.06 11:09:37 LOG7[13]: 13 internal session cache item(s)

2015.05.06 11:09:37 LOG7[13]: 0 internal session cache fill-up(s)

2015.05.06 11:09:37 LOG7[13]: 0 internal session cache miss(es)

2015.05.06 11:09:37 LOG7[13]: 0 external session cache hit(s)

2015.05.06 11:09:37 LOG7[13]: 0 expired session(s) retrieved

2015.05.06 11:09:37 LOG6[13]: SSL accepted: new session negotiated

2015.05.06 11:09:37 LOG6[13]: No peer certificate received

2015.05.06 11:09:37 LOG6[13]: Negotiated TLSv1 ciphersuite AES128-SHA (128-bit encryption)

2015.05.06 11:09:37 LOG7[13]: Compression: null, expansion: null

2015.05.06 11:09:37 LOG6[13]: Failover strategy: round-robin

2015.05.06 11:09:37 LOG6[13]: s_connect: connecting 127.0.0.1:1234

2015.05.06 11:09:37 LOG7[13]: s_connect: s_poll_wait 127.0.0.1:1234: waiting 10 seconds

2015.05.06 11:09:37 LOG5[13]: s_connect: connected 127.0.0.1:1234

2015.05.06 11:09:37 LOG5[13]: Service [psudo-tcp] connected remote server from 127.0.0.1:54891

2015.05.06 11:09:37 LOG7[13]: Remote socket (FD=444) initialized

2015.05.06 11:09:38 LOG3[13]: readsocket: Connection reset by peer (WSAECONNRESET) (10054)

2015.05.06 11:09:38 LOG5[13]: Connection reset: 140 byte(s) sent to SSL, 225 byte(s) sent to socket

2015.05.06 11:09:38 LOG7[13]: Remote socket (FD=444) closed

2015.05.06 11:09:38 LOG7[13]: Local socket (FD=548) closed

2015.05.06 11:09:38 LOG7[13]: Service [psudo-tcp] finished (0 left)

It's a bit different from the log in "Troubleshooting" section, but as far as I can understand from this log, we do manage to create a session and for some reason the client resets the connection.

The only difference in our configuration is the port numbers, but I don't think this is the source of the problem.

[EBara5]

I'm still trying to identify the problem. So after going over the reference again I noticed one interesting thing.

In section 4.3.3 the IP which is specified for Http, Socks and SOAP is 10.10.10.100. I'm wondering what does this IP represent? In the https://youtu.be/SM-XpcQrg0w?t=43s video tutorial the address is 192.168.1.1. In our configuration we set this address to 127.0.0.1 (because the proxy resides on the same machine). So, say we've got an Amazon server instance with IP 123.456.78.9. What shall we specify in the MPS configuration?

[EBara5]

Following the guide to the letter did the work. Thanks!

[Anonymous]

Excellent, glad you found the guide useful!

Regards

- Martin.