Forum Discussion
Anup_Km
Nimbostratus
NimbostratusUnable to connect to virtual server with curl -v xx.xx.xx.xx:8443 or 443
Hi, I have created one Virtual Server in LTM Big IP F5 BIG-IP 14.1.0.2 Build 0.0.4 Point Release2 Port number I used while creating is 443 https service. Also Pool Members are from different subnet...
Nikoolayy1
MVP
MVPAgain the F5 uses a self ip to talk to the server not the VIP address that is for the client. Please see what I provided and maybe check:
Anup_KmNimbostratus
NimbostratusNo. I am not taking to telnet F5 Virtual Interface from Putty or any management Server.
I have already taken CLI inside working LB thorugh its management IP.
I tested telneting another virtual Server configured in same LB with Virtual IP with command
telnet xx.xx.xx.xx 443 ........................ it works
However for this perticular Virtual Server when I do same with telnet xx.xx.xx. 8443 or 443 it does not work.
- Anup_Km
Mentioned Articles I went through; It is not relevent for this issue.
As SSL Certificate is not terminated on F5 for Server I am having issue with on LTM.
Management routes and Management IP are totally different from Virtual IP instance.
Routing will not take any part in performing telnet to same IP which is only virtaul instance in BIG IP F5. Other working Virtual Server IP are allowing me to telnet inside (atleast i am getting prompt) from inside CLI login of Selft BIG IP F5. With this perticular Virtual Server IP there is issue; Even Pool memebers which are configured with 8443 Port allowed to be telnet when performed from CLI prompt of BIG IP F5; only self IP does not give telnet enable with port 8443 or 443; there must be some configuration issue with this Virtual Server; but I tested all configuration.
Including SNAT: Client Profile; Server Profile; VLAN setting; all are as per working Virtual server only; but when I run Curl command or telnet session of Virtual server IP it gives connection refused; that means port 8443 or 443 is not allowing to set up telnet connection.
CA_ValliI would 100% perform a packet capture on F5 and check both client-side and server-side flows to see where does the drop come from.
If F5 actively rejects the configuration, there might be some misconfiguration. are you running HTTP profile on an HTTPS virtual server without SSL certs by any chance? this would be a problem beause F5 tries to retrieve standard http headers but only sees encrypted data.