We recently solved a problem that had us stumped for a while. We installed a new Exchange 2007 Server for a client. They are using a Sonicwall SSL VPN 2000 for remote access that is configured to use one-time passwords. The existing Exchange 2003 server was used to send out the one-time passwords.
We needed to move the one-time password sending duties over to the new Exchange 2007 Server, so we created a Receive Connector on the Exchange 2007 server that allowed relaying from the SSL VPN 2000 appliance. But when we changed the SSL VPN 2000 to use the new Exchange 2007 server, all of the users received an error message that a one-time password could not be sent.
Logging on the Exchange 2007 Receive Connector was set to Verbose to see why a one-time password could not be sent. But the logs did not record any connection attempts from the SSL VPN 2000 when it was configured to use the Exchange 2007 Server. Of course, as soon as we changed the mail server back to the old Exchange 2003 server everything worked fine.
A review of the static routes on the SSL VPN 2000 under Network, Routes showed that in addition to the Default Gateway, a static route was added for the local subnet with a default gateway of the firewall. Bingo! Of course, a static route for a local subnet is not necessary and can cause potential problems. In this case when we changed the mail server for one-time passwords over to the Exchange 2007 Server, the static route routed the request to the firewall, where it was dropped. That's why there was no record of a connection attempt from the SSL VPN 2000 in the Exchange 2007 Receive Connector log, because the request never got to the Exchange 2007 Server! Deleting the static route for local subnet and leaving the default gateway in tact solved the problem.
Hopefully you will catch this blog post and save yourself a lot of pain.