Forum Discussion
imabbas_90
Altocumulus
AltocumulusSFTP VIP on CLoud F5 AWS not working from internet , from F5 its working
Hello, we have an SFTP VIP configured on AWS Cloud F5 with some high number port 41415 for VIP with private IP and Pool configured with port 22.
Vip: private IP, performance L4, automap enabled. Fast L4 profile attached. No Http profile
Pub to Private IPs is Tagged on the Cloud end
Now when we do telnet to the VIP with port 41415 from the internet it's not working. we tried to open WinSCP with the public IP of the VIP with port 41415 it's not working. But we can see the logs like end-user IP towards the VIP IP only Sync almost 3 to 4 packets in TCP dumps.
When we do Telnet to the VIP with private IP from the F5 device it's working.
Telnet to port 22 to the End SFTP AWS server is working from F5 . Kindly advise how to make this work from the internet.
So from packet capture, you see TCP SYN hitting F5 and no response? Nothing is forwarded to the real SFTP server on a server side connection, correct?
Looks like SYN packet might be dropped, I'd check that packet data in your pcap are actually matching the configuration.
First thing I'd check is that your network configuration is on point for the client-side connection - eg. F5 has a default route back to client IP, Virtual Server is listening on intended VLAN.
Next, match the packet from your capture to VS and confirm service port and IP are correct, and client IP belongs to a network that's included in source network list.If everything is spot-on, you need to investigate VS secifications further as there might be some profile "conflicting" with your traffic or likely preventing the match, but you said this is a fastL4 so that's quite unlikely imo.
Hi Thanks for your input. We found the issue. Its the AFM and Zone was wrongly marked for the destination.
Again thanks.
CA_ValliMVP
So from packet capture, you see TCP SYN hitting F5 and no response? Nothing is forwarded to the real SFTP server on a server side connection, correct?
Looks like SYN packet might be dropped, I'd check that packet data in your pcap are actually matching the configuration.
First thing I'd check is that your network configuration is on point for the client-side connection - eg. F5 has a default route back to client IP, Virtual Server is listening on intended VLAN.
Next, match the packet from your capture to VS and confirm service port and IP are correct, and client IP belongs to a network that's included in source network list.If everything is spot-on, you need to investigate VS secifications further as there might be some profile "conflicting" with your traffic or likely preventing the match, but you said this is a fastL4 so that's quite unlikely imo.
imabbas_90Hi Thanks for your input. We found the issue. Its the AFM and Zone was wrongly marked for the destination.
Again thanks.
- Ritks12
Nimbostratus
Based on the information provided, it seems like there might be a few potential issues causing the problem with accessing the SFTP server from the internet. Here are a few things to check:
- Check your security group settings on AWS. Ensure that the security group attached to the instance running the SFTP server allows traffic from the internet on port 41415.
- Verify that your F5 load balancer is configured properly. Ensure that the virtual server for the SFTP VIP is configured to listen on port 41415 and forward traffic to the appropriate pool members on port 22. Make sure that the F5 device is able to route traffic to the SFTP server in your private subnet.
- Check any firewalls or other network devices between the F5 and the SFTP server. Ensure that traffic on port 41415 is allowed through these devices.
- Verify that the NAT rules on the F5 are configured properly. Make sure that traffic from the internet on port 41415 is being NAT'd to the private IP of the SFTP server.
- Check the logs on the F5 to see if there are any error messages or other indicators of a problem.
If you've checked all of these things and are still having issues, it may be helpful to engage your network or security team to help troubleshoot the issue further.
- imabbas_90
Hi Thanks for your input. We found the issue. Its the AFM and Zone was wrongly marked for the destination.
Again thanks.