Ask a Question

Rebex TLS Proxy - Problems connecting to Azure SQL

0 votes
by (120 points)

Hi,
I am trying to setup Rebex TLS Proxy to allow us to use legacy applications that doesn't support TLS 1.2 to connect to our Azure SQL manged instance that only supports TLS1.2.

When using this config without cert, the connection somehow fails:

tunnels:
- name: sqlserveraddress.database.windows.net:1433
  in:
    port: 1433
  out:
    address: sqlserveraddress.database.windows.net
    port: 1433
    protocol: TLS
    tlsVersions: TLS12
  idleTimeout: 120


2025-03-21 16:06:01.396 [INF] Tunnel(1)[#0 'server'][O]: Connection secured using cipher: TLS 1.2, RSA with ephemeral ECDH, AES with 256-bit key in GCM mode, AEAD.
2025-03-21 16:06:01.396 [INF] Tunnel(1)[#0 'server'][-]: Established tunnel (127.0.0.1:50058) --'plain'--> (1433) --'TLS12'--> (sqlserveraddress.database.windows.net:1433).
2025-03-21 16:06:01.396 [DBG] Tunnel(1)[#0 'server'][-]: Endpoints: IN=[127.0.0.1:50058; 127.0.0.1:1433], OUT=[10.221.2.8:50059; 10.221.1.201:1433].
2025-03-21 16:06:01.412 [DBG] Tunnel(1)[#0 'server'][I]: Using modern transport layer.
2025-03-21 16:06:01.412 [DBG] Tunnel(1)[#0 'server'][-]: Forwarding 52 bytes (IN ==> OUT).
2025-03-21 16:06:01.412 [DBG] Tunnel(1)[#0 'server'][-]: Forwarding 37 bytes (IN <== OUT).
2025-03-21 16:06:01.412 [DBG] Tunnel(1)[#0 'server'][-]: Forwarding 184 bytes (IN ==> OUT).
2025-03-21 16:06:01.428 [DBG] Tunnel(1)[#0 'server'][-]: Forwarding 196 bytes (IN <== OUT).
2025-03-21 16:06:01.428 [DBG] Tunnel(1)[#0 'server'][O]: TLS socket was closed abruptly.
2025-03-21 16:06:01.428 [DBG] Tunnel(1)[#0 'server'][-]: Forwarding from inbound tunnel finished (IN ==> OUT).
2025-03-21 16:06:01.428 [DBG] Tunnel(1)[#0 'server'][-]: Closing tunnel from 127.0.0.1:50058.
2025-03-21 16:06:01.443 [DBG] Tunnel(1)[#0 'server'][O]: (closing) Rebex.Net.TlsException: Connection was closed by the remote connection end.
2025-03-21 16:06:01.443 [DBG] Tunnel(1)[#0 'server'][-]: (closing) Error while receiving data (IN <== OUT): Rebex.Net.TlsException: Connection was closed by the remote connection end.
2025-03-21 16:06:01.443 [DBG] Tunnel(1)[#0 'server'][-]: Forwarding from outbound tunnel finished (IN <== OUT).
2025-03-21 16:06:01.443 [INF] Tunnel(1)[#0 'server'][-]: Tunnel from 127.0.0.1:50058 closed.

Any clues how I can troubleshoot this?

I thought that perhaps the incoming tunnel would need TLS as well but when trying to add a cert it fails all the time. 

tunnels:
- name: sqlserveraddress.database.windows.net:1433
  in:
    port: 1433
    certificate: D:\www.domain.com.cer; key=D:\www.domain.com.pri
    protocol: TLS
    tlsVersions: TLS10,TLS11,TLS12,TLS13
  out:
    address: sqlserveraddress.database.windows.net
    port: 1433
    protocol: TLS
    tlsVersions: TLS12
  idleTimeout: 120

I can validate the certs with command,
tlsproxy certinfo "D:\www.domain.com.cer; keyD:\www.domain.com.pri"
But the config fails with error

Service "RebexTlsProxy" is starting ERROR Cannot start service
'RebexTlsProxy' on computer '.'. System.InvalidOperationException:
Cannot start service 'RebexTlsProxy' on comput er '.'. --->
System.ComponentModel.Win32Exception (1053): The service did not
respond t o the start or control request in a timely fashion. ---
End of inner exception stack trace --- at
System.ServiceProcess.ServiceController.Start(String[] args) at
System.ServiceProcess.ServiceController.Start() at
irq.<>c.bxr(ServiceController wn) at irq.dul(Action1 wi, ServiceControllerStatus wj) at irq.dui() at iru.<>c.wgr(irq xu) at irt.qza[b](String xl, Func2 xm) at iru.pvd(String xq) at
irs.usx() at Rebex.TlsProxy.Cli.SvcStartCliOptionsBase.Run(irs
handler) at iov.Handle(SvcStartStopCliOptionsBase op) at
System.Dynamic.UpdateDelegates.UpdateAndExecute2[T0,T1,TRet](CallSite
site , T0 arg0, T1 arg1) at iov.uvu(VerbOptionsBase f) at
ioz.Main(String[] args)

Adding nothing to the log file, the event log records
YamlDotNet.Core.YamlException: (Line: 4, Col: 5, Idx: 101) - (Line: 4, Col: 5, Idx: 101): Exception during deserialization ---> System.Runtime.Serialization.SerializationException: Property 'certificate' not found on type 'Rebex.TlsProxy.Config.TlsProxyConfiguration+Endpoint'.

Any clues? :)

Applies to: Rebex TLS

1 Answer

0 votes
by (75.9k points)

You placed the certificate into in: section, which is invalid. The certificate needs to be placed outside (at the same level as in, out, idleTimeout. Please try this instead:

tunnels:
- name: sqlserveraddress.database.windows.net:1433
  in:
    port: 1433
    protocol: TLS
    tlsVersions: TLS10,TLS11,TLS12,TLS13
  out:
    address: sqlserveraddress.database.windows.net
    port: 1433
    protocol: TLS
    tlsVersions: TLS12
  certificate: D:\www.domain.com.cer; key=D:\www.domain.com.pri
  idleTimeout: 120

Also, I suggest to use only tlsVersions: TLS10,TLS11,TLS12 in the in: section since you are only connecting with legacy clients. Please note that enabling TLS13 requires additional resources, which is not needed in your case.

by (120 points)
Thanks, got it to start now. However I am getting the same error when trying to connect to our Azure SQL Managed instance.

I don't know if our Azure SQL is picky with what cert we are using to connect to it. But can you come up with any thing else to tweak?



sqlserveraddress: Connection from 127.0.0.1:56373 accepted on 127.0.0.1:1433.
sqlserveraddress: Starting tunnel (127.0.0.1:56373) --'TLS10,TLS11'--> (1433) --'TLS12'--> (sqlserveraddress.database.windows.net:1433).
sqlserveraddress: Assembly: Rebex.Tls 8.0.9148 for .NET 6.0
sqlserveraddress: Platform: Windows 6.1.7601 Service Pack 1 32-bit; CLR: .NET 6.0.36
sqlserveraddress: Culture: sv; windows-1252
sqlserveraddress: Starting TLS negotiation.
sqlserveraddress: Using TLS 1.2 core.
sqlserveraddress: Enabled cipher suites: 0x0C1F3CF3EBC00600.
sqlserveraddress: Applicable cipher suites: 0x00000030C0C00600.
sqlserveraddress: Using modern transport layer.
sqlserveraddress: (127.0.0.1) Cannot start inbound tunnel due to: Rebex.Net.TlsException: Connection was closed by the remote connection end.
sqlserveraddress: Cannot start inbound tunnel due to: Rebex.Net.TlsException: Connection was closed by the remote connection end.
by (75.9k points)
Can you please turn on more detailed log (Verbose):

logging:
  global:
    location: D:\logs\
    minLevel: Verbose

And send the produced log to support@rebex.net for analysis.
by (120 points)
Provided logs from an attempt connecting with both plain and with TLS.
by (120 points)
Solved!

If anyone else stumbles on this thread this is how I got it working.

When running Rebex TLS Proxy on the same server as the client connecting to the TLS Proxy, you need to add the address to the Azure SQL-server to your local hosts file amd route it to IP: 127.0.0.1

Then in your configuration file add the IP-address, perhaps private endpoint? in Azure, as address in the out-section. Then use the setting sniOverride to add the FQDN of the Azure SQL Managed Instance.

config.yaml

tunnels:
- name: AzureSQLInstance:1433
  in:
    port: 1433
  out:
    address: 10.0.1.10
    port: 1433
    protocol: TLS
    tlsVersions: TLS12
  idleTimeout: 120
  sniOverride: sql-managed-instance.database.windows.net
by (75.9k points)
Thank you for sharing the solution. I will add the explanation why this was necessary:

Previously, your application accessed the Azure SQL-server (through TLS Proxy) using "localhost" FQDN, but the Azure SQL-server was not able to correctly login for "localhost".

When updated hosts file (c:\Windows\System32\drivers\etc\hosts), the application now access the Azure SQL-server (through TLS Proxy) using correct FQDN (e.g. sqlserveraddress.database.windows.net).

However, because sqlserveraddress.database.windows.net is now routed to 127.0.0.1, it cannot be used for out-address in the TLS Proxy config (it would route to itself), so an IP address must be used to identify the target (e.g. `address: 10.0.1.10`).

Finally, it is often required by the TLS server implementations to provide SNI extension. If out-target is an FQDN, the SNI extension is filled with that value. But, in case an IP address is used for out-address, it must be set explicitly using `sniOverride` (e.g. `sniOverride: sql-managed-instance.database.windows.net`).
...