Send Connector Routing problems
Hi Experts, I have an question about send connectors in Exchange 2007 SE. I have configure 2 send connectors: First one: Primaire Internet Service Provider KPN Mail Relay Smarthost KPN Priority 1 (cost) Domains * Second one: SecundaireInternet Service Provider PublishNet Mail Relay Smarthost PublishNet Priority5 (cost) Domains * We have also and Cisco Router with fail-over ISP. When the primaire internet service provider is active, then all mails sending through the Send Connector First One. The KPN send connector does have more priority and relay permissions. (primaire ISP). Everything is correct. When the secundaire internet service provider is active, and the primaire internet service provider is down, then all mails must be routed throug the Send ConnectorSecond One. (Because we don`t have relay permissions on first send connector - other public ip adres). The problems is, that Exchange everytime wants to user the Send Connector First One. Butthe companydon`t have relay permissions on it and want to use Send ConnectorSecond One. (Backup ISP) Does somebody know how to auto force this? I hoping that everything is fixed with the cost value, but thats not. Thanks,
July 26th, 2008 3:44pm

I think the send connector will not failover to the "second one" because it can, in fact, still communicate with the "first one". The fact that the "first one" disallows relay isn't a good enough reason for the send connector to failover. Perhaps make a firewall rule that disallows smtp connections to KPN from the PublishNet wan link. This way, Exchange would see the "first one" as unavailable, and fail to the next one. I haven't used send connectors in this way before, so i'm not 100% sure this is how they work, but does that sound feasable?
Free Windows Admin Tool Kit Click here and download it now
July 26th, 2008 5:14pm

Hi Mike, Thanks for replying my request. I have an Cisco Systems ASA5505 Firewall with three vlans (inside, outside, backup). Do you know how i can make an rule form inside to backup segment without affecting the rule inside to outside? Thanks, Bart.
July 26th, 2008 6:10pm

Again, before we go down this path, i'm not sure this is even how send connectors work. i'm not sure if they have cost for the purpose of failing-over, or if its only for taking a path that would otherwise be included in a more generic connector. I've only used the later implementation. (MAYBE SOMEONE ELSE CAN SPEAK TO THIS) As for your firewall, i'm not an expert on the ASAs, but from whatI know, they can do pretty much anything. I believe you would be allowed to make a rule based on interface, and not just the zones you've mentioned. Maybe its a CLI only option if it seems impossible from the GUI. I'd have to fiddle with it and possibly hit Cisco's support site. I would structure the rule to state: deny smtp from <wan2 interface or ip if NATed> to primary IP. You could also consider adding authentication to the send connector. Maybe the ISP is disallowing relay becauase its from a forign net. But if you authenticate, you could send through anyway.
Free Windows Admin Tool Kit Click here and download it now
July 27th, 2008 1:24am

Hi Bart, I would like to explain that send connector will not failover to the second one even if the Smarthost KPN is down. In Exchange 2007, the messages are routed based on Address Space matching and lowest cost. Thus, the message will not be rerouted in case the Smarthost KPN is down. If you would like to have the send connector failover to the second one, I am afraid that you have to disable the first connector or change the cost. After that, the old message will be rerouted to the second connector when the message is retried. The new message will select the second connector automatically. Mike
July 31st, 2008 4:48am

Good to know, thanks for clearing that up. Bart, what do you think about the authentication suggestion? The other obvious option would be to just let Exchange route email via mx records.
Free Windows Admin Tool Kit Click here and download it now
July 31st, 2008 7:14am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics