Forum Discussion
Roberto_78444
Nimbostratus
NimbostratusSSL Problem
Hello I have a BigIp 1600 LTM and I configured an https virtual server with no http profile and no SSL profile.
When I try the following command to the vip i get an error:
openssl s_client -connect 192.168.1.224:443 -state
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:error in SSLv2/v3 read server hello A
write:errno=104
If I run the same command directly to the server it works fine.
Any ideas?
- dennypayne
Employee
Hi,
How is the pool set up that the virtual points to? If you aren't using an SSL profile then you aren't decrypting, so the pool members need to be listening on 443 as well.
Denny 
Roberto_78444yes each of the servers in the pool are listening on port 443. It's strange cause through a browser in windows I can get information from the server through https://.
hoolioCirrostratus
Maybe you need SNAT enabled on the virtual server if the server's default gateway isn't the BIG-IP?
Aaron- Roberto_78444Hello Aaron, that seems to be the problem, thanks a real lot for that. Can you explain why this is the case?
Thanks,
Dean - Roberto_78444The problem with the above is that i seem to be getting always the IP of the load balancer on my access logs. Also the BIG-IP is actually the default gateway for the server.
- hoolioHi Dean,
If the server's default gateway is the BIG-IP's floating self IP address on the VLAN that the server is on, then you shouldn't need SNAT and the requests should work without SNAT enabled. If it only works with SNAT enabled, then the routing config on the server is probably the issue. Does the server have multiple NICs? Maybe the non-SNAT'd connections are being sent out the wrong interface on the server?
A review of the server's routing along with a tcpdump on the BIG-IP and server should help you isolate the issue.
Aaron - Roberto_78444Hello Aaron,
It is actually a virtual machine with a single NIC, could it be a problem that the source ip, the virtual server ip and the destination server ip are all on the same network? - hoolioThe issue with that scenario without SNAT is that the client establishes a TCP connection with the VIP. LTM opens a connection to the server spoofing the client IP. Because the server is on the same subnet as the client, it just ARPs for the MAC address for the client IP and responds back directly to the client. The problem is the server responds using it's IP--which isn't what the client made the request to. So the client doesn't accept the response.
To handle this you can:
1. Not test using a client on the same subnet
2. Enable SNAT (for all clients or just those on the same subnet using a Selective SNAT iRule Click here)
3. Use nPath to allow the server to respond back directly to the client using the VIP address as a source
1 and 2 are easy--three is a bit more convoluted in that it intentionally uses asymmetric routing. You can find more info on nPath by searching the forums or AskF5 for nPath.
Aaron - Roberto_78444I will test using option 2 tomorrow. Will let you know my results, thanks again.
Dean - Roberto_78444Thanks Aaron, Looks like it working fine using option 2. Need to introduce a 2nd load balancer for redundancy into the setup. Are there any resources that can help?
Dean
