Forum Discussion
Joel_106642
Nimbostratus
NimbostratusSSL LTM 9.3 can't get it to work
We tried to cut over to a new pair of 6400s which have an ASM module. The F5 uses a virtual network server for all traffic to the inside vlan that doesn't require loadbalancing. All of the VIPs worked corrected for all traffic except for SSL traffic. The SSL certificates reside on the servers and not the F5. The VIPs supporting SSL are set up with port 80 and 443 so that when someone connects on 80 they are redirected to 443. This all works fine on our old BigIPs 4.x code. I have not touched the ASM config at this time. Not sure what to do with it anyway. Also, I use the following IRule on each VIP to support bounceback.
when LB_SELECTED {
if {[IP::addr "[IP::client_addr]/24" equals "[LB::server addr]/24"]} {
snat automap
} else {
snat none
}
}
Can anyone point me in the right direction.
Joe_Willis_4776We had a similar situation; to make sure I understand then your VIP's service port is 443 right? In our case, it's because we assigned an HTTP profile to the VIP...but this isn't HTTP traffic (it's HTTPS traffic). Setting HTTP profile to None for the VIP fixed our problem.
Joel_106642At first we setup a "server ssl" profile then removed all profiles. But no luck. When we used the acutal server address it would connect, but if we pointed to the VIP it would not. One thing unusual on the server is there are two IP addresses assigned to an interface and only one has the default route associated with it. And that IP is not the IP used in the Pool. The server has multiple IPs do represent multiple hosts.
hoolioCirrostratus
First, I'd suggest considering upgrading from 9.3.x to 9.4.5 with the latest hotfix (currently HF2). ASM and the architecture between TMM and ASM have both been completely revamped in 9.4.5. The security policy format and methodology have also changed significantly since 9.3.x. If you're just starting out with ASM you might want to use the new format.
That said, if you're having issues configuring an ASM-enabled VIP, try removing any HTTP classes you've added to the VIP. Start with a standard TCP VIP on port 443. To make the test simple, configure the pool members on port 443 and don't decrypt the client traffic or re-encrypt the server traffic with SSL profiles. Once you get that working, then you can start with the decryption and adding ASM to the VIP.
When you add ASM, you'll need to decrypt the client side traffic to parse it as HTTP and inspect it. So you'll need to add a client SSL profile and an HTTP profile. If you need to keep the server side traffic encrypted, add a server SSL profile. Get that working and then add an HTTP class with App Security enabled. Make sure the policy is in transparent mode to start with. Once you get the load balancing configuration set up, you can start building the policy.
If you have issues with the load balancing configuration reply here. If you have questions on the ASM portion of the configuration, you can post in the new ASM forum (Click here).
Aaron- Joel_106642Thank you for the information. The VIP that we created was a normal, non ASM VIP, and without any profile, we could not get an SSL connection to work through the LTM. We thought that maybe it had something to do with the fact that I had that iRule on the VIP. But in the meantime we can look at upgrading the code because that sounds important. At this point I wouldn't even know how to setup an ASM VIP. If there is something else you can think of please let me know.
- hoolioFor upgrading I say 'consider' 9.4.5HF2. 9.3.1 is more stable as it's a maintenance release. 9.4.5 will have much better performance for ASM and the new ASM policy format--but it's less stable. You would get better out of the box security with the ASM attack signatures in 9.4.5. And you'd avoid having to build a 9.3.x format policy and have to migrate that to the new 9.4.5 format. So I wouldn't say it's an automatic decision.
The SNAT iRule should work find as long as you have a floating self IP address on the VLAN that the traffic to the pool would go through. You could simplify the configuration for your basic initial test by just applying SNAT automap on the VIP for all connections. Once that's working, you can add the iRule.
Was the HTTP VIP whcih was working referencing pool members on the same subnet as the HTTPS VIPs' pool? There shouldn't be any difference in configuration between a standard TCP VIP defined on port 80 versus one defined on port 443. So if the port 80 VIP was working correctly, just copy that config and use it for the port 443 VIP. Once that's working you can add the more complex objects like client and server SSL, the SNAT iRule, an HTTP profile and eventually an HTTP class with App Security enabled.
Aaron - Joel_106642Will do.. Thanks Aaron.