Forum Discussion
kraigk_52257
Nimbostratus
NimbostratusSMTP STARTTLS iRule
I need help with getting a STARTTLS iRule working for SMTP on our 1600's. We are on version 10.2.1. And to be clear it is working but there are a few tweaks I can't figure out. The main issue is that when I telnet to the VIP I can't do an SMTP conversation. It throws "530 Must issue a STARTTLS command first". If I fire up Outlook Express I am able to use port 25/TLS just fine and the smtp.log with Outlook Express shows a normal conversation. How to get the conversation to work? Here is the code:
when CLIENT_ACCEPTED {
SSL::disable
}
when SERVER_CONNECTED {
TCP::collect
}
when CLIENT_DATA {
set lcpayload [string tolower [TCP::payload]]
if { $lcpayload starts_with "ehlo" } {
TCP::respond "250-STARTTLS\r\n250 OK\r\n"
TCP::payload replace 0 [TCP::payload length] ""
TCP::release
TCP::collect
} elseif { $lcpayload starts_with "starttls" } {
TCP::respond "220 Ready to start TLS\r\n"
TCP::payload replace 0 [TCP::payload length] ""
TCP::release
SSL::enable
} else {
TCP::respond "530 Must issue a STARTTLS command first\r\n"
TCP::payload replace 0 [TCP::payload length] ""
TCP::release
TCP::collect
}
}
when SERVER_DATA {
TCP::release
clientside { TCP::collect }
}
asharicz_6648No worries Colin, just glad I am getting good enough with the iRules I might actually be able to help someone else out!- I'll say ;) Keep up the good work.
Colin - asharicz_6648Hey all, revisiting this one. I got real close to production with this rule, until I found that some hosts cannot send (namely messagelabs cannot not negotiate TLS with this iRule), they are spitting back an error that TLS was not supported.
In my own testing, using various POP clients or checkTLS.com, everything works, SSL is negotiated properly.
So then I tried out OpenSSL as suggested here, and I seem to be getting the dreaded "250 Chunking" error the OP got earlier. SSL appears to be negotiated, but every subsequent command in the session returns an "unrecognized command" from the SMTP server in the pool. I can see in the SMTP logs what the server sees, it is getting unprintable characters added on to the end of the commands I input. So say I connect open ssl, I negotiate TLS, and I type "ehlo" the server log will show that I connected and typed ehlo(Open SSL does this), TLS nego is then done unknown to the SMTP server, then I type "ehlo" but the SMTP server sees "ehlo█" in the log .
I am not quite sure what is going on here. I am guessing the "250 chunking" is a bit of a red herring, as in the problem is not the "chunking" but it is telling that that is the last line of the server response to the client "ehlo" greeting, the one the iRule inserts the "250 Starttls" into. So I am thinking some sort of collection buffer issue with the BIGIP, due to the way the rule is formatted. Why that makes every command after TLS negotiation corrupt is beyond me! It is getting way over my head to udnerstand what is going on.
I also tried the exact rule from this thread and the repository, as it was when it "worked" for the OP here, but it still has this "250 Chunking" issue.
There was a discussion of fixing this issue from the earlier rules, but neither Nat nor Damion explained why this probem happened? If I knew why it happened with the earlier versions of this iRule I might have a better idea of what is wrong with this one.
I am about give up on TLS offloading with the BIGIP, too bad because it would have save much time and effort being able to run multiple mailhosts with TLS off the same server pool. 
Nat_ThirasuttakornEmployee
Hi Asharicz,
> There was a discussion of fixing this issue from the earlier rules, but neither Nat nor Damion explained why this probem happened?
actually, I never see that error myself. The issue I remember was we tried to support both client that support and the one that doesn't
you see the error on server? may I ask what server are you using?
can you post the packet trace? (please make sure it does not contain any sensitive information)
Nat- asharicz_6648
Nat,
Thanks for the reply. I could get the packet trace, but thinking about it, I am not sure which side I should trace? The outside interface is just recieving standard traffic and TLS negotiation, though maybe I would want to compare what a "working" client like checktls or Outlook does compared to non-working OpenSSL client.
If I capture on the inside, I would just capture the odd traffic that gets sent to the SMTP server, which is already in my SMTP logs, which doesn't really help either.
If you look back, the OP was talking about a "250 chunking" return when trying to get TLS negotiation working, do you see those posts in this thread? I am wondering what the actual problem with the iRule was there, because I seem to be having it with some SMTP clients even with the latest version posted here.
It seems the problem is inside the logic of the iRule, I'm not sure how to get to what the problem is there, other than logically working through the iRule in my mind, which hasn't worked out well so far ;-)
The SMTP server is an Exchange 2007 HUB server. I could easily put another type of SMTP server behind that pool to test if it is an interaction specific to the Exchange 2007 server.
