Question
· Jun 14, 2023

TCP Adapter - Local Interface setting

Forgive me but our System Administrator who knows how the networking works is OOO...

How does IRIS know which local adapters are available to populate in an Inbound or Outbound TCP Adapter Object? We recently moved from HealthShare Health Connect 2018.1.3 to IRIS HealthShare Health Connect  2022.1. When we migrated we moved the VIP over to the new box and set it at the hardware level.

On RedHat when I do an ifconfig I have two ens192 adapaters..

ens192: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 8900
        inet xxxxxx  netmask xxxxx broadcast xxxxxxxx
        inet6 xxxxxxx  prefixlen 64  scopeid 0x20<link>
        ether xxxxxx  txqueuelen 1000  (Ethernet)
        RX packets 2844737404  bytes 489525499847 (455.9 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2890261627  bytes 6219593374601 (5.6 TiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ens192:1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 8900
        inet xxxxxxx  netmask xxxxxx broadcast xxxxxx
        ether xxxxx txqueuelen 1000  (Ethernet)

the ens192:1 represents the VIP. So we have set the Local Interface in our connections that use VPN to the address that ens192:1 represents. However, the networking team is saying they are seeing packets with the IP address of ens192 not the VIP. 

If we have the Local Interface set to the correct IP address that it should represent, why would the network folks see the other IP address in the packet as we are trying to troubleshoot a new VPN connection?

Product version: IRIS 2022.1
Discussion (2)1
Log in or sign up to continue

Thanks, we tried taking an existing connection that was using the Local Interface Address of the VIP (ens192:1) and tracing it through the firewall to see what IP address it was associated with.

When we changed the port on the existing connection even though the Local Interface was set to the VIP, it started to send the other IP address assocated with ens192.

But if we changed the port back to the original port with the Local Interface set to the VIP it reverted back to sending the VIP in the packet header. 

I am questioning if we truly stop/started the object after making the change, but that is here nor there. 

I did open a ticket with WRC to get more information on how to troubleshoot the Local Interface setting, and the TCP Adapters definitions.