We have known for a while that some people on eduroam in Oxford (not elsewhere) sometimes have trouble connecting to Nexus (as you know, a Microsoft Exchange service). There is about a 1 in 64 chance of a given device seeing this issue. I hope not too many folk have spent lots of time trying to diagnose Nexus connection issues resulting from this bug!
OUCS has now worked out that it is because Microsoft ISA server appears to ignore RFC1519 (which facilitates classless inter-domain routing) and assumes that 184.108.40.206 (being a pre-RFC1519 class C address) is a broadcast address so won’t talk to it. This is not good as RFC1519 dates back to 1993 – the year many of the current freshers were born and well before Exchange existed! Big thanks to the Nexus team and the Network Support and Development team for their work on this, particularly to Rob Zachlod for his detective work.
Oxford eduroam’s DHCP gives private RFC1918 addresses (from 10.16.0.0/12) to clients and then these are translated by NAT to addresses in the range 192.76.7.(192-255) in a predictable way by an elegant algorithm. This means that if a client gets an address that maps to 220.127.116.11 then it won’t be able to talk to Nexus (and presumably any other Microsoft ISA servers in the world). The predictability of the mapping means that client (strictly its MAC address) is effectively stuck in that state in that location of eduroam as the DHCP pool is large so clients will not get a different lease very often. Note that there are several segments of eduroam in the University with separate DHCP pools in the above range so the problem may appear to resolve for a client that moves to a different part of the University (but will probably come back when it moves back to the problem location).
In order to fix this problem, the Networks Support and Development team have kindly agreed to change the way the eduroam NAT maps to public routeable IP addresses so that the 18.104.22.168 address will no longer be used. The change will not introduce mappings to addresses that were not already in use before it so nothing should break but the remapping will disconnect any connection-based protocols so SSH sessions etc will terminate for eduroam clients but connectionless things like web browsing (where state is maintained by cookies, not IP protocols) should be fine. After the change it should be trivial to re-establish connected sessions.
The plan is to do this change in the at-risk period on Tuesday morning 11 October between 7am and 9am. Please let us know if you foresee any problems with the change.
We are sorry if this will cause any inconvenience but after a lot of abortive efforts to get it fixed we have taken the view that it is easier to work around the Microsoft bug than wait for a fix.
Finally, please note that this is not a problem with eduroam but a problem with Microsoft that we can work around by reconfiguring eduroam for Oxford. It would presumably affect any device with a (or that NAT-maps to a) class C address that ends in .255 or indeed a class B that ends in .255.255