c++sslquickfixfix-protocolstunnel

QuickFix C++ and SSL: Issue connecting to LMAX using sTunnel

Goal:

Using sTunnel with QuickFix C++: To login to the LMAX UAT over SSL-internet and send FIX 4.2 messages over a TCP connection. Another similar SO question can be found here, but doesn't appear to solve this particular issue.

OS: Ubuntu 19.10 | sTunnel version: 5.55 | Engine: quickfix-1.15.1 | Venue: LMAX [UAT-LD4]

Problem:

Cannot login to the UAT. After starting sTunnel and then running the client application which first sends a LOGON message, no authentication is received. LMAX have said the client server public IP addr has been whitelisted.

*Configs found further below. When trying to login:

20210130-12:40:45.207811000 : Created session
20210130-12:40:45.208201000 : Connecting to 127.0.0.1 on port 143 (Source :0)
20210130-12:40:45.208384000 : Initiated logon request
20210130-12:40:55.217130000 : Socket Error: Connection reset by peer
20210130-12:40:55.217148000 : Disconnecting

The outbound LOGON message (taken from log) seems to adhere to the LMAX FIX specifications (please ignore the incorrect checksum as credentials have been changed). This may suggest that the issue lies with the TCP connection. The outbound LOGON message:

8=FIX.4.2|9=104|35=A|34=1|49=SENDER_XYZ|52=20210130-12:40:45.208309000|56=TARGET_XYZ|95=12|96=PASSWORD_XYZ|98=0|108=15|10=094|

Expected result: To receive a LOGON authentication from LMAX.

Results:

After following this tutorial on installing and using sTunnel on Ubuntu. , sTunnel is then started with sudo systemctl start stunnel4.service and the service status checked, giving: enter image description here

Once sTunnel is started, after starting the client application packets can be seen in Wireshark going from the client server to the LMAX UAT, but it seems that no packets are returned from LMAX UAT.

System Logs

Running journalctl -xe produces the following logs.

  1. While sTunnel is running: https://pastebin.com/YE6xyNcM

  2. While sTunnel is running, and client app has been started and then stopped: https://pastebin.com/Vv55A35L

Configuration and Setup

SSL certificates were generated using the following commands:

openssl genrsa -out key.pem 2048
openssl req -new -x509 -key key.pem -out cert.pem -days 1095
cat key.pem cert.pem >> /etc/stunnel/stunnel.pem

*The sTunnel config:

pid = /var/run/stunnel4/stunnel.pid

[LMAX-UAT]
client = yes
accept = 127.0.0.1:143
connect = fix-order.london-uat.lmax.com:443
sslVersion = TLSv1
verify = 2
CApath = /etc/ssl/certs/
cert = /etc/stunnel/stunnel.pem
checkhost = fix-order.london-uat.lmax.com

*The QuickFix config:

[DEFAULT]
ConnectionType=initiator
HeartBtInt=15
ReconnectInterval=2
FileStorePath=store
FileLogPath=log
StartTime=00:00:00
EndTime=00:00:00
UseDataDictionary=N
SocketConnectHost=127.0.0.1
SenderCompID=SENDER_XYZ
SocketUseSSL=N
TimestampPrecision=9

[SESSION]
BeginString=FIX.4.2
TargetCompID=TARGET_XYZ
SocketConnectPort=143

Summary Questions:

  1. Given the above details, can anyone determine what is preventing FIX communication over SSL-internet to the UAT at LMAX?
  2. Based on the Wireshark activity, could this be a sTunnel issue instead of the formatting of the initial LOGON message?
Solution

  • SOLUTION:

    It appeared that indeed the IP address (as helpfully noted by @Christoph John) had not been correctly whitelisted by the server-side.

    However, the problem persisted. In the sTunnel configuration, I had to change sslVersion = TLSv1.1 to sslVersion = TLSv1.2.

    As well as this, it appears that the UAT would not accept FIX 4.2 messages. After changing the protocol version to FIX 4.4, I could finally LOGON to the UAT.