Forum Discussion
crate_17871
Nimbostratus
Nimbostratussame subnet lb + SSL
Guys,
Having an issue with full communication with some remote devices.
The network set as follows:
Handheld devices communicate via GPRS to a router through a firewall to a pair LTM 1600 terminating an SSL connection which then connects to a server for service offered.
The handheld devices as 1.1.1.0/24 goes to a NAT in front of the firewall for the LTM 2.2.2.2:30000 (TCP)
The LTMs configured with IP 3.3.3.3/24 and ClientSSL takes this traffic and gives this to a server 3.3.3.4:20000.
The gateway for the LTMs are 3.3.3.1 (firewall interface) and the server is 3.3.3.20 (router interface).
The initial connection setup is done however the devices are not completing the connection to retrieve the data.
Can anyone start with a nudge or a point in the right direction?
Almost forgot when doing some dumps, saw some TCP Zero Window Segments
Jason_KeatingAltostratus
Not 100% sure I have understood your network config - sounds like a one-arm config, if your server 3.3.3.4 has a default gateway other than the ltm you likely need to set up a SNAT on the ltm. I'd recommend a configuring a SNAT Pool with at least one self IP from the VLAN of egress.
Cspillane_18296I'd agree with jmkakabarb, try SNAT on the Virtual Server (either use AutoMap or create your own pool of addresses which should all be on the egress VLAN i.e. the VLAN where traffic leaves the BigIP to go to the server).
crate_17871I wanted to do this however I will have to show all ips to the server
and on this particular VLAN not much free ips for to provide to the clients for an entire /21 mask.- Chris_MillerPosted By crate on 09/07/2010 07:29 AM
I wanted to do this however I will have to show all ips to the server
and on this particular VLAN not much free ips for to provide to the clients for an entire /21 mask.
What do you mean by "show all ips to the server" - crate_17871The Server providing the service must see all devices IP in order to communicate efficiently. If any duplicates are seen the Server will drop the connection
HamishCirrocumulus
That's not fatal. The only requirement is that the F5 see both flows of the TCP connection. So you then have 2 choices.
1. Implement policy based routing such that all traffic FROM the poolmember port on the server is routed via the F5 (Floating IP)
2. Or simply put the F5's floating selfip as the default router.
3. Move the servers off to a dedicated subnet BEHIND the F5...
Option 1 is cleaner... At the expense of some systems won't let you do this... Linux and iptables are pretty simple (I've done it myself, takes a couple of iptables lines to tag the packets and a tagged packet routing table entry). Option 2 is not as clean and has the disadvantage that hosts on the same subnet (Besides the F5 of course) will be unable to access the load balanced service (That may or may not be a problem for you). Option 2 & 3 also require a wildcard network VS to be created on the F5 and also a route TO the servers via the F5 from the actual router (It starts to get messy on option 2 pretty rapidly).
H- crate_17871Posted By Hamish on 09/07/2010 08:33 AM
That's not fatal. The only requirement is that the F5 see both flows of the TCP connection. So you then have 2 choices.
1. Implement policy based routing such that all traffic FROM the poolmember port on the server is routed via the F5 (Floating IP)
2. Or simply put the F5's floating selfip as the default router.
3. Move the servers off to a dedicated subnet BEHIND the F5...
Option 1 is cleaner... At the expense of some systems won't let you do this... Linux and iptables are pretty simple (I've done it myself, takes a couple of iptables lines to tag the packets and a tagged packet routing table entry). Option 2 is not as clean and has the disadvantage that hosts on the same subnet (Besides the F5 of course) will be unable to access the load balanced service (That may or may not be a problem for you). Option 2 & 3 also require a wildcard network VS to be created on the F5 and also a route TO the servers via the F5 from the actual router (It starts to get messy on option 2 pretty rapidly).
H So let me outline the specifics of this solution.
The F5 receives the traffic via a VS, which is then sent to a Swtichware device on the same subnet. The device has a router in front with the same subnet address and has a route to point back to the F5 to reach the handheld devices. The F5 forwards this traffic through a firewall to reach this network.
The solution is basically for SSL offloading, so the devices can connect through ssl for some encryption, the f5 then forwards this traffic after offloading the ssl to the server which requires all connecting IPs to be shown, the server is to send this to f5 for re encryption and send to the handheld.
I hope this helps, cause been taxing myself trying to get this thing working. - HamishMm.... No... I wasn't suggesting extra hardware...
H - Jason_KeatingRe Hamish's suggestion:
3 is going to greatly simplify things for you, of course its a bigger change but you will not look back once its done.
If 3 is not going to happen 1 is the next best option in my opinion (and a great idea, I'll be stealing that one Hamish). Hamish's suggestion here is to configure this on the server(s) (i.e. 3.3.3.4 as referenced in your first post) as a result no extra hardware is required.
If (port of egress = 20000)
{
gateway = ltm_floating_ip
} else {
} - crate_17871Guys,
thanks alot, I modified the TCP profile and turned off port translation and things worked well. I now want to optimize the settings, so i'll play around abit with the settings in the custom TCP profile.
Again thanks alot for all the help.
