SMTP iApp Template - Early Release
Problem this snippet solves:
INITIAL RELEASE
Minimum required BIG-IP version: 11.4.0. Supported BIG-IP versions: 11.4.0-12.0
v1.0.0rc1 iApp template for configuring standard load balancing, monitoring, SSL offloading, and TCP optimization for Simple Mail Transfer Protocol (SMTP). The template also supports deploying F5's Advanced Firewall Manager (AFM), when AFM is licensed and provisioned.
v1.0.0rc2 There were no changes to the functionality in this release. Minor changes to clarify some of the questions and answers. Added inline help entries.
v1.0.0rc3 Fixed an issue with the associated cli script that could prevent users from importing iApp templates.
v1.0.0rc4 Fixed an issue with selecting password-protected encryption keys. To use a password-protected encryption key, you must create an SSL profile that uses the key and specify that profile where indicated in the iApp template.
v1.0.0rc5 Fixed an issue with incorrectly formatted external monitor scripts.
v1.0.0rc7 Fixed an issue with monitors utilized in the server-side ssl scenarios, as a result the openssl eav monitor is used in the 'no msg submitted' monitor scenarios. A fifth monitor option was presented as well to break the 'auth/no msg' option into basic and ntlm so the iApp can use openssl if Basic(auth login) is selected. - This release also allows a custom receive string to be specified(advanced must be selected).
v1.0.0rc8 Minor updates and enhancements to the monitor choices.
For the associated deployment guide, see [http://www.f5.com/pdf/deployment-guides/f5-smtp-dg.pdf]
Contributed by: F5
Code :
83126
Tested this on version:
12.0Published Apr 30, 2015
Version 1.0
- The-messenger
Cirrostratus
does this iapp support passing source-ip to the smtp nodes - instead of the f5 ip?
Hi The-messenger, it supports that if you disable SNAT in the iApp and set the default gateway of the SMTP servers to the self IP address of the BIG-IP.
- The-messenger
I've seen that as a proposed solution before but I don't think setting the default gateway for your all your Exchange servers to the self-ip of the Big-IP is a viable solution. There is more going with Exchange than mail relay.
Your other option is to use nPath: https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm_implementations_guide_10_1/sol_npath.html
TMK, for non-HTTP traffic, those are the only ways to get the real source IP.
- The-messenger
Is this not possible with an irule? I don't need to change the route, just want Exchange admins to be able to see the source address for delivery troubleshooting.
Normally you could use the HTTP profile or an iRule if the traffic is HTTP. However I just found this DC post you might try:
 
https://devcentral.f5.com/s/feed/0D51T00006j2p4ZSAQ
 
- The-messenger
Mike, where is the limitation in adding x-header data to SMTP stream. I've worked with multiple email filtering systems that add x-header data.
This could be very valuable in managing smtp traffic.
patrick_hayesNimbostratus
We see the same error as etrust made 1 week ago. Mike?
Hello Etrust and Patrick, This issue has been resolved. Please download the template and try again! Let us know if you have any additional feedback, thanks.
Hello Anders, The problem here is that when doing any of the SSL scenarios it will try and create an external monitor, this requires some additional TCL commands. This should work in almost all environments, however my guess is you are using a user account that does not have the administrator role?
Basically the scenario where this can occur with some of the tcl commands being called in various iApps is if the user has a “non-admin” role such as resource administrator assigned to them on the big ip they can create an iApp, but if it uses certain executables within the deployment of that iApp then those get blocked as a result of a security feature on the BIG-IP.
If this is the case for you then the recommended solution is to run the iApp as an administrator, an alternative would possibly be to use your own monitor in the iApp which should cause those sets of commands being run to not be run, but you might run into another invalid TCL command use case as a result.
Let me know if this is(or isn't) the case...
