Exchange 2007 externe connecties werken niet of nauwelijks

Pagina: 1
Acties:

  • UltraSub
  • Registratie: Mei 2003
  • Laatst online: 05-02 11:41
Heb een probleem met mijn Exchange server. Sinds een week werkt ineens OWA (en push) voor geen meter meer. Soms kan ik normaal werken, soms krijg ik gewoon time outs. Ben inmiddels al een week aan het troubleshooten, en het zoeken op internet, maar ik lijk nu muurvast te zitten. Vandaar dit topic, misschien komt het probleem hier iemand bekend voor, en kan iemand me helpen.

Situatie:

code:
1
2
3
4
5
Ziggo modem
        |
Debian firewall / iptables       ----    LAN clients
        |
Server 2008 / Exchange 2007



Ik draai dus Server 2008 (met laatste updates), en Exchange 2007 SP1 (rollup ben ik even kwijt zoek ik nog terug). SSL certificaten komen van GoDaddy, en zijn volledig in orde.
Alles heeft maanden vlekkeloos gewerkt. Zowel push als OWA, zowel intern als extern. Sinds een week heb ik grote problemen met externe connecties naar Exchange. Zowel op de firewall als op de server zelf is niets gewijzigd, het probleem trad ineens op. Ik kwam er achter omdat ik ineens last had van een iPhone die ontzettend snel leeg was, en na wat onderzoek bleek push niet of nauwelijks te werken (dus hoog battery gebruik). Dus ben ik gaan testen.
Intern werkt alles nog steeds vlekkeloos, zowel Outlook clients via RPC, als OWA via SSL (default 443) en ActiveSync. Sync ik mijn telefoon vanaf het interne netwerk, dan blijft de push sessie (ook volgens logging) gewoon actief en werkt perfect. OWA performed super, inloggen gaat snel, en de mailbox/kalender/contacts browsen werkt ook supersnel. Dus intern gewoon geen enkel probleem!
Dan extern. Hier werkt het soms wel, en soms niet. Meestal niet. En dat is raar naar mijn mening. Het probleem manifesteert zich doordat OWA vanaf een externe locatie niet te benaderen is, of zeer zeer langzaam, waarna vaak alsnog een timeout (blank page, geen foutmelding) verschijnt. Probeer je het een uur later, werkt het vlekkeloos en zo snel als de lijn toelaat. Gewoon soepeltjes. Voor ActiveSync geldt hetzelfde. Meestal werken push verbindingen niet, maar af en toe wordt er toch een connectie opgezet, en kan ik syncen. Vraag je na korte tijd een refresh, geen probleem. Is de connectie weggeweest, en moet die opnieuw opgebouwd worden, dan is het weer drama.

TCP dumps op de firewall, laten zien dat de packets/requests wel binnenkomen op de debian doos. Iptables output laat zien dat packets normaal door zouden moeten kunnen. De firewall rules zijn overigens al jaren ongewijzigd, en port 443 (en wat andere ports voor Exchange, die eigenlijk niet eens nodig zouden zijn) is gewoon geforward naar het interne ip adres van Exchange.

Lang verhaal kort:
Ik denk dat er iets mis is op het gebied van mijn provider. Helaas kan ik dat niet hard maken. Geen ping timeouts of packet loss. Browse ik fotoalbums op mijn Apache server, dan flitst dat. Zodra verkeer over 443 moet, gaat het mis.
Het feit dat ik intern alles werkend heb, inclusief OWA en push, en het sóms ineens van extern uit wel perfect werkt, doet mij vermoeden dat het probleem niet bij mij ligt. Daar komt nog bij dat ik een SBS 2003 van een vriend beheer, en die heeft ineens ook problemen met sync en extern benaderen van OWA. En daar is ook niks gewijzigd.

Ik ben uit-getroubleshoot. Ik kom niet meer verder, weet niet waar ik het moet zoeken. Ik hoop dat iemand me verder kan helpen, of in ieder geval op weg kan helpen. Hoop dat er voldoende informatie in deze post staat, en dat mijn probleem duidelijk beschreven is.

  • _Arthur
  • Registratie: Juli 2001
  • Laatst online: 21:20

_Arthur

blub

UltraSub schreef op woensdag 13 mei 2009 @ 11:43:
Het feit dat ik intern alles werkend heb, inclusief OWA en push, en het sóms ineens van extern uit wel perfect werkt, doet mij vermoeden dat het probleem niet bij mij ligt. Daar komt nog bij dat ik een SBS 2003 van een vriend beheer, en die heeft ineens ook problemen met sync en extern benaderen van OWA. En daar is ook niks gewijzigd.
Die vriend heeft dezelfde provider? Zoja, welke provider praten we hier over?

  • UltraSub
  • Registratie: Mei 2003
  • Laatst online: 05-02 11:41
Yup... Het gaat hier om Ziggo. :)

  • UltraSub
  • Registratie: Mei 2003
  • Laatst online: 05-02 11:41
Naja.. alles ook hier niemand me verder kan helpen, dan denk ik niet dat er veel anders op zit dan het domein opnieuw op te bouwen en Exchange van scratch te installeren. Is de laatste stap om mijn eigen setup uit te sluiten.

  • alt-92
  • Registratie: Maart 2000
  • Niet online

alt-92

ye olde farte

meh.

Werkt het intern wel goed? Dan heeft een complete rebuild geen zin want je probleem zit niet in je install.
Kijk liever eens naar je packet size als je alleen problemen hebt met https verkeer.

Je firewall is overigens ook een suspect in die zin. Dáár geen updates op geweest?

[ Voor 96% gewijzigd door alt-92 op 15-05-2009 17:46 ]

ik heb een 864 GB floppydrive! - certified prutser - the social skills of a thermonuclear device


  • _Arthur
  • Registratie: Juli 2001
  • Laatst online: 21:20

_Arthur

blub

UltraSub schreef op vrijdag 15 mei 2009 @ 16:45:
Naja.. alles ook hier niemand me verder kan helpen, dan denk ik niet dat er veel anders op zit dan het domein opnieuw op te bouwen en Exchange van scratch te installeren. Is de laatste stap om mijn eigen setup uit te sluiten.
Dat lijkt me weinig van toegevoegde waarde aangezien je meld dat intern het wel goed werkt.

Of werkt dat ook soms wel, soms niet?

Ik zou eerder in netwerk/switch/router/firewall dit probleem zoeken dan aan de Exchange kant.

  • UltraSub
  • Registratie: Mei 2003
  • Laatst online: 05-02 11:41
alt-92 schreef op vrijdag 15 mei 2009 @ 17:44:
meh.

Werkt het intern wel goed? Dan heeft een complete rebuild geen zin want je probleem zit niet in je install.
Kijk liever eens naar je packet size als je alleen problemen hebt met https verkeer.

Je firewall is overigens ook een suspect in die zin. Dáár geen updates op geweest?
Ja, intern werkt als een trein. Ik ga er ook vanuit dat het niet in mijn install zit, maar ik wil een of ander eventueel vaag, moeilijk te vinden, probleem in AD uit kunnen sluiten op deze manier. Het is een gevirtualiseerde omgeving (ESX 3.5 U4), dus vrij makkelijk te testen (afgezien van de uren die er in gestoken moeten worden). Werkt de nieuwe omgeving ook niet, Oude systeem booten, en alles is weer als vanouds. Aan de andere kant, als ik dan toch alles opnieuw heb gedaan, kan ik misschien beter die paar mailboxen importeren, en doorgaan op een frisse omgeving, ongeacht of de problemen met activesync vanaf externe adressen nog steeds aanwezig zijn. Weet ik nog niet, zie ik dan wel.

Vwb de firewall... 200% zeker geen updates. En omdat het super straightforward is, is het ook makkelijk uit te sluiten. Was het ISA, dan zou ik niet zo zeker zijn. Een update links of rechts kan iets vernaggelen in Windows natuurlijk. In Linux en iptables wordt dit toch wel een ander verhaal.
1. Er zijn geen updates geweest
2. De rules zijn nog exact gelijk als die van twee jaar geleden. Naja, waren ten tijde van het probleem. Heb nu al wel enigszins gevlooid, maar de originele rules heb ik ook nog, en als ik die draai werkt het ook gewoon niet.
_Arthur schreef op vrijdag 15 mei 2009 @ 22:07:
[...]

Dat lijkt me weinig van toegevoegde waarde aangezien je meld dat intern het wel goed werkt.

Of werkt dat ook soms wel, soms niet?

Ik zou eerder in netwerk/switch/router/firewall dit probleem zoeken dan aan de Exchange kant.
Zoals ik hierboven al beschrijf, inderdaad, je hebt volledig gelijk. Maar ik kan niks vinden... 8)7

  • alt-92
  • Registratie: Maart 2000
  • Niet online

alt-92

ye olde farte

Zoals gezegd, ga eens met je packet size spelen.
Vroeger, met de KPN PPTP verbindingen waren er soms ook wel eens problemen met niet fragmenterende packets > 1492 waardoor met name https verbindingen liepen te bokken.

Kun je ook zien door met wireshark te sniffen, je ziet dan relatief veel RSETs en retransmissions bijvoorbeeld.

ik heb een 864 GB floppydrive! - certified prutser - the social skills of a thermonuclear device


  • UltraSub
  • Registratie: Mei 2003
  • Laatst online: 05-02 11:41
Heb van de week even een kogelnieuw AD en Exchange opgebouwd. Pre-cies hetzelfde probleem.
AD en Exchange zijn dus uitgesloten van het probleem.

Ben nu aan het testen met een ander toestel, en een andere provider. Als die wel werkt, dan ligt het aan T-Mobile. Als die niet werkt, dan kom ik toch bij Ziggo (of inderdaad iets in mijn eigen netwerk, maar dat is zeer onwaarschijnlijk) uit.

/edit
Zeer interessant. Push met KPN 3G lijkt vooralsnog vlekkeloos te werken.
Met Wireshark op de Exchange bak aan het loggen, source adres dat van de telefoon, en geen enkele error te zien. Draai ik het filter om, dus op destination adres dat van de telefoon, dan rammelt het werkelijk van de checksum errors met als source adres de Exchange doos.
1. Waar komen die nou vandaan vraag ik me af
2. Waarom lijkt KPN daar niet over te vallen, en T-Mobile geeft errors dat hij niet kan verbinden met de server.
Zou het soms zo zijn dat mijn server vernaggelde packets stuurt, en dat KPN dat niet interesseert, en T-Mobile ze dropped of zo?

/edit 2
KPN push werkt nog steeds vlekkeloos. Wel checksum errors van Exchange naar KPN adres, maar geen retransmits (heel af en toe).
T-Mobile werkt voor geen meter. Constant retransmits. Ook checksum errors van Exchange naar T-Mobile adres, maar gezien het feit dat KPN dat niet lijkt te interesseren om een push connectie werkend te houden, denk ik dat de checksums het probleem niet zijn.
Maar dus wel zeer interessant van T-Mobile verkeer.
Ik ben geen netwerkman, dus snap niet zo goed wat hier gebeurd. Het feit dat de server een retransmit doet, en niet de mobiele kant, kan ik daar iets uit af leiden? Zijn die retransmits daadwerkelijk mijn probleem? Het lijkt er wel op, maar misschien kan iemand dit bevestigen. Zo ja, wat heb ik dan voor vervolgstappen? T-Mobile bellen zal weinig opleveren denk ik :X

/edit 3
En wat ik op het net vind over Wireshark en checksums:
Checksums are rarely wrong, so look at the checksum value in the trace. If it is TCP and 0000 (zeros) then the problem is probably bogus.

The source of this is usually the fact the TCP checksums-offload are enabled in the NIC driver and so many of the packets (the ones to/from this machine) have their checksums not calculated until the actual NIC gets ready to transmit the frame.

Wireshark can't tell so it calls it in error.
Dus.. ik ga er vanuit dat ik de checksums wel weg mag strepen, en me kan focussen op de retransmits.

[ Voor 87% gewijzigd door UltraSub op 22-05-2009 13:50 ]


  • _Arthur
  • Registratie: Juli 2001
  • Laatst online: 21:20

_Arthur

blub

UltraSub schreef op vrijdag 22 mei 2009 @ 12:59:
Heb van de week even een kogelnieuw AD en Exchange opgebouwd. Pre-cies hetzelfde probleem.
AD en Exchange zijn dus uitgesloten van het probleem.
Niet verrassend eerlijk gezegd.
KPN push werkt nog steeds vlekkeloos. Wel checksum errors van Exchange naar KPN adres, maar geen retransmits (heel af en toe).
T-Mobile werkt voor geen meter. Constant retransmits. Ook checksum errors van Exchange naar T-Mobile adres, maar gezien het feit dat KPN dat niet lijkt te interesseren om een push connectie werkend te houden, denk ik dat de checksums het probleem niet zijn.
Maar dus wel zeer interessant van T-Mobile verkeer.
Ik gebruik een Exchange 2007 omgeving op mijn @Home lijn en Tmobile op m'n Iphone samen push email / owa whatever werkt uitstekend.

Check je netwerk eens, dus router/modem/switch/kabels/etc. Ook omdat je met KPN ook dezelfde 'problemen' ziet alleen in mindere maten.

  • UltraSub
  • Registratie: Mei 2003
  • Laatst online: 05-02 11:41
_Arthur schreef op vrijdag 22 mei 2009 @ 15:56:
[...]

Niet verrassend eerlijk gezegd.
Vind ik ook niet verrassend, maar ik wilde het wel uitgesloten hebben. En dat is nu dus gebeurd.
[...]

Ik gebruik een Exchange 2007 omgeving op mijn @Home lijn en Tmobile op m'n Iphone samen push email / owa whatever werkt uitstekend.

Check je netwerk eens, dus router/modem/switch/kabels/etc. Ook omdat je met KPN ook dezelfde 'problemen' ziet alleen in mindere maten.
Dan hebben we dus exact dezelfde setup ;)
Maar met KPN zie ik dus niet dezelfde problemen! Heel heel af en toe een retransmit. Maar dat is normaal, en is gewoon TCP. Voor T-Mobile zie ik niets dan retransmits. Wireshark logt heel veel checksum errors, maar goed, dat is afgetikt. Is inherent aan hardware offloading blijkbaar.

Ben ik net gaan bellen met TM helpdesk, valt me tijdens het gesprek in dat ik één ding niet heb getest. Ik heb de iPhone niet uitgesloten! :X Daartoe zou ik ff de TM sim in de TyTN moeten stoppen waar ik de KPN verbinding mee heb getest. Helaas kan ik de KPN sim niet in de iPhone stoppen, want die is simlocked. Maar door de TM sim in de TyTN te testen, zou ik het toestel toch wel uit moeten kunnen sluiten. Vanavond ff testen.

Maar goed, er is dus nu een case aangemaakt bij TM. Ik word terug gebeld. Ben benieuwd.

  • _Arthur
  • Registratie: Juli 2001
  • Laatst online: 21:20

_Arthur

blub

UltraSub schreef op vrijdag 22 mei 2009 @ 16:25:
Dan hebben we dus exact dezelfde setup ;)
Behalve dan dat ik geen firewall gebruik.
Ben ik net gaan bellen met TM helpdesk, valt me tijdens het gesprek in dat ik één ding niet heb getest. Ik heb de iPhone niet uitgesloten! :X
Is je iPhone gejailbraked? De mijne is dat niet.

En kwa retransmits e.d. heb ik te weinig kaas van gegeten om daar wat zinnigs over te zeggen ;)

  • UltraSub
  • Registratie: Mei 2003
  • Laatst online: 05-02 11:41
_Arthur schreef op vrijdag 22 mei 2009 @ 16:53:
[...]

Behalve dan dat ik geen firewall gebruik.

[...]

Is je iPhone gejailbraked? De mijne is dat niet.

En kwa retransmits e.d. heb ik te weinig kaas van gegeten om daar wat zinnigs over te zeggen ;)
Ja.. iPhone is jailbreaked.. of broken, of whatever :)

Ben nu aan het testen met TyTN II icm TM sim die in de iPhone dus niet werkt.
Het rammelt nu ook van de retransmits, maar het lijkt wel te werken.

/edit
Nope, de TM sim in de TyTN (die met de KPN sim perfect werkt dus), krijgt het ook niet voor elkaar om de boel te syncen. Waar de iPhone meteen een melding geeft dat er geen contact gemaakt kan worden met de server, blijft de TyTN alleen wat langer proberen (dus nog meer retransmits volgens WireShark). Als ik WireShark goed interpreteer vinden er vaak retransmits plaats voor frames die 20 seconden eerder al verstuurd waren. Ja kom op zeg, dat kan toch ook niet werken?

Dit gaat een hele leuke worden om opgelost te krijgen met TM helpdesk :( ;(
Ik hoor het ze al zeggen daar: "Dus u heeft wel internet meneer, u kunt surfen? Nou ja, dan werkt alles toch?"
* UltraSub zucht alvast voor de neverending story die nu gaat beginnen.

/edit 2
Omdat het dus geen Exchange probleem is, zal ik dan maar een nieuw topic ergens anders op GoT aanmaken over dit probleem. (of een mod moet een geschikte plaats weten, dit topic willen moven en een titeledit doen O-) )
Bedankt voor de input mensen!

[ Voor 50% gewijzigd door UltraSub op 22-05-2009 20:09 ]


  • _Arthur
  • Registratie: Juli 2001
  • Laatst online: 21:20

_Arthur

blub

UltraSub schreef op vrijdag 22 mei 2009 @ 19:42:
Dit gaat een hele leuke worden om opgelost te krijgen met TM helpdesk :( ;(
Ik hoor het ze al zeggen daar: "Dus u heeft wel internet meneer, u kunt surfen? Nou ja, dan werkt alles toch?"
* UltraSub zucht alvast voor de neverending story die nu gaat beginnen.
Gewoon zeggen dat internet dus maar half/niet werkt ;)

  • UltraSub
  • Registratie: Mei 2003
  • Laatst online: 05-02 11:41
Gelukkig was het topic nog niet gesloten :P
Verder onderzoek, naar waarom OWA zo langzaam is, vanaf een willekeurige internetverbinding. WireShark gebruikt, en hey, wat ziet mijn oog? Ook een rammel retransmits. Het is dus niet (alleen) T-Mobile. Vraag is waarom KPN dan wel een push connectie kan onderhouden. :?

Heb net de drivers van de Intel E1000 nic geupgrade naar laatste level, maar dat mocht niet baten.
Ik ga straks als ik thuis ben eens even kijken of ik ook retransmits zie als ik lokaal werk. Begint nu toch wel erg verdacht te worden.

  • _Arthur
  • Registratie: Juli 2001
  • Laatst online: 21:20

_Arthur

blub

UltraSub schreef op dinsdag 26 mei 2009 @ 13:29:
Gelukkig was het topic nog niet gesloten :P
Verder onderzoek, naar waarom OWA zo langzaam is, vanaf een willekeurige internetverbinding. WireShark gebruikt, en hey, wat ziet mijn oog? Ook een rammel retransmits. Het is dus niet (alleen) T-Mobile. Vraag is waarom KPN dan wel een push connectie kan onderhouden. :?

Heb net de drivers van de Intel E1000 nic geupgrade naar laatste level, maar dat mocht niet baten.
Ik ga straks als ik thuis ben eens even kijken of ik ook retransmits zie als ik lokaal werk. Begint nu toch wel erg verdacht te worden.
Gooi die firewall er eens tussen uit als test.

  • UltraSub
  • Registratie: Mei 2003
  • Laatst online: 05-02 11:41
Was ik ook al aan het denken. Gaat alleen niet zó makkelijk als het klinkt.
Maar zal zeker de volgende stap moeten zijn.

  • UltraSub
  • Registratie: Mei 2003
  • Laatst online: 05-02 11:41
Oeioei.. Net ergens tegenaan gelopen! MTU size! Geen idee waarom die ineens anders stond.
Ik kwam er op omdat ik dit zag met tshark:

86.048521 XX.XXX.XXX.XX -> XX.XXX.XXX.XX IP Fragmented IP protocol (proto=TCP 0x06, off=0)
86.048538 XX.XXX.XXX.XX -> XX.XXX.XXX.XX TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

Ben ik gaan Googlen, en zag dat het nog wel eens kón zitten in de MTU size. Nou wist ik dat die altijd op 1500 stond (automatisch, nooit handmatig iets aan gedaan). Ik check, en zie:

viper:~# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:0c:29:6b:d7:44
inet addr:XX.XXX.XXX.XX Bcast:255.255.255.255 Mask:255.255.254.0
UP BROADCAST RUNNING MULTICAST MTU:576 Metric:1
RX packets:2503201 errors:0 dropped:0 overruns:0 frame:0
TX packets:957174 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1945239890 (1.8 GiB) TX bytes:87017426 (82.9 MiB)
Interrupt:18 Base address:0x1424

Dus:
viper:~# ifconfig eth0 mtu 1500

En nu VEEL minder retransmits. Er komt nog wel eens wat langs, maar dat is natuurlijk 1. inherent aan TCP, en 2. zeker inherent aan mobiele netwerken..
Even vingertjes kruisen dat dit het was. In ieder geval lijkt push nu veel beter te werken. Time will tell. Ik ga niet meer te vroeg roepen dat dit het probleem was, te vaak van een koude kermis thuis gekomen. Maar het lijkt er stiekem wel op :X

  • alt-92
  • Registratie: Maart 2000
  • Niet online

alt-92

ye olde farte

Zie je wel? :)

ik heb een 864 GB floppydrive! - certified prutser - the social skills of a thermonuclear device


  • UltraSub
  • Registratie: Mei 2003
  • Laatst online: 05-02 11:41
Yup, je had het meteen bij het rechte eind. Hulde ;)
alt-92 schreef op zaterdag 16 mei 2009 @ 19:14:
Zoals gezegd, ga eens met je packet size spelen.
Vroeger, met de KPN PPTP verbindingen waren er soms ook wel eens problemen met niet fragmenterende packets > 1492 waardoor met name https verbindingen liepen te bokken.

Kun je ook zien door met wireshark te sniffen, je ziet dan relatief veel RSETs en retransmissions bijvoorbeeld.
Maar goed.. Het werkt allemaal weer als een tierelier. Bedankt mannen!!

/edit
En de reden waarom die lage MTU er was, is me inmiddels ook al duidelijk. Alles staat fixed ingesteld, behalve de externe interface, die doet DHCP omdat Ziggo dat graag wil. De nieuwste DHCP clients honoreren de MTU waarde die de DHCP server mee kan geven. De client is niet gewijzigd, die heeft het altijd gehonoreerd. Wat mij zoveel zegt als dat een of andere DHCP wijziging aan de kant van Ziggo is doorgevoerd. Of mijn verbinding zit op een andere DHCP server waar een foute setting staat, enz..

[ Voor 26% gewijzigd door UltraSub op 28-05-2009 14:29 ]

Pagina: 1