web stats
TCP Listener not binding to 'Specific Interface'? - Mirth Community

Go Back   Mirth Community > Mirth Connect > Support

Reply
 
Thread Tools Display Modes
  #1  
Old 02-05-2020, 07:15 AM
jridderhoff jridderhoff is offline
OBX.1 Kenobi
 
Join Date: Jan 2015
Posts: 42
jridderhoff is on a distinguished road
Default TCP Listener not binding to 'Specific Interface'?

We're in a setup where we are using stunnel in front of the ports that Connect listens on for security. For example, the server's public IP listens on port 7001, stunnel is set up to proxy that to port 7001 on the IPv4 loopback (127.0.0.1) that isn't publicly accessible, as well as to add SSL encryption.

In cases where we've set up Web Service Listeners and indicated that the listener should bind the port only on 127.0.0.1. This works great; looking at the active ports, you can see stunnel using port 7001 on the external IP, mcservice using 7001 on IPv4 loopback.

Yesterday, we needed to do the same for some channels that are TCP Listeners. We set everything up the same way, configured the Listener Settings such that 'Specific Interface' was selected and '127.0.0.1' was specified. When we tried to deploy the channel, we got exceptions about the socket already being in use. We tried starting the sockets up in the other direction (starting the Mirth channel first, then stunnel), but stunnel then complained about the socket already being in use--despite Mirth being configured to bind it only on IPv4 loopback and stunnel specifically being configured to bind it to the external IP address.

Through some more troubleshooting, we discovered that whenever we deployed a TCP Listener channel, no matter what Local Address is selected in the Listener Settings, a TCP Listener channel binds to all interfaces (mcservice is shown using the port on both 'IPv4 unspecified' and 'IPv6 unspecified').

We ran into this problem using Connect 3.7.0 on Windows Server 2012, but a review of the release notes for all later versions doesn't show any changes related to the topic, and another colleague tried using 3.8.0 on a Linux server and experienced the same symptoms, so it seems to be either intentional or a systemic bug. Having the configuration options in a TCP Listener to be able to bind to a specific interface seems to imply that it should work, but it's definitely not.

I've tried searching, both locally here in the forums and via external search engines, to see if this was a known issue, but I couldn't find any substantial mention of it. Is this a bug, a feature, or are we doing something wrong?
Reply With Quote
  #2  
Old 02-05-2020, 03:24 PM
agermano agermano is offline
Mirth Guru
 
Join Date: Apr 2017
Location: Indiana, USA
Posts: 1,176
agermano is on a distinguished road
Default

It seems to be an undocumented "feature" of the TCP Listener. It specifically checks to see if the specified host is a loopback address, 'localhost', or the server hostname, and then creates a server socket that isn't bound to a particular address. I have no idea what the purpose of this is.

I recommend opening a ticket, since the Web Service Listener, DICOM Listener, and HTTP Listener don't have this same odd logic.

https://www.mirthcorp.com/community/issues/browse/MIRTH
Reply With Quote
Reply

Tags
interface, stunnel, tcp listener

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -8. The time now is 03:58 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2020, vBulletin Solutions, Inc.
Mirth Corporation