I noticed that at one of the customers I have that uses low-end business MTS has had their NTP incoming/outgoing port (UDP 123) cut off (filtered) at the ISP. Incoming I can understand, but outgoing? All the computers in the office have their time out of sync now.
Does anyone know what the internal Bell/MTS time server's IP/domain is? Surely they didn't cut us off to their internal one.
Will have the customer contact them eventually, but you know how it goes with tech support. Looking for the quick solution...
Anyone else have their UDP 123 cut off since Bell came along?
Further: it looks like they are filtering outgoing only if your source port is also 123. That is hardcoded into ntp (from what I've read). But ntpdate allows the -u option to have the src port be >1024. I tried that and ntpdate -u does work, but ntpdate without the -u gets blocked. So they really are blocking in and out, but only src=123udp.
Looks like chrony (and others) lets you specify src port, but I'm loathe to uproot the system I know because Bell is braindead. (MTS didn't use to block it, and block-happy Shaw does not block it.)
On 2019-01-25 Trevor Cordes wrote:
Looks like chrony (and others) lets you specify src port, but I'm loathe to uproot the system I know because Bell is braindead. (MTS didn't use to block it, and block-happy Shaw does not block it.)
Epiphany moment: iptables can probably solve this. 20 minutes later:
iptables -t mangle -A OUTPUT -o $iext -p udp --sport 123 --dport 123 -j MARK --set-mark 30 iptables -t nat -A POSTROUTING -p udp -m mark --mark 30 -j SNAT --to-source :60000-61000
Works perfectly! ntpd now syncs with peers. ntpdate doesn't need -u. I don't need to switch to chrony. And I don't need to wait for ntpd to add this feature*. Go take a hike Bell!!!
*http://bugs.ntp.org/show_bug.cgi?id=1109 ... looks like never
Note, it could be just 1 rule, but I used 2 to make sure that I only SNAT packets originating from within the actual firewall/router itself, and not packets being forwarded from within the internal LAN (PC's). I can't figure out a way to specify "really originated locally" other than with mark, but I'm open to ideas. It's not as easy as it sounds with multiple interfaces on the box, unless there's a trick I'm missing.
If I wanted internal LAN PCs to also have their traffic go through, I'd need to use a -j MASQUERADE (it's a dynamic IP) in an extra rule and change the syntax slightly. Since all internal PCs should be set to use the firewall as ntp server, this shouldn't be a problem (in fact could help me id broken PC ntp setups).
One of my favorite sayings is "never suspect a conspiracy, that which can be explained by incompetence". This is likely an accidental side effect of something else they've done because unless they are now trying to sell you some kind of Bell branded time-sync service, I can't think of any business reason why they would do this intentionally.
Although, one thing I can think of is, perhaps there is a whole lot of unsecured NTP on their network being actively exploited?
Might be worth going through the pain of opening a ticket to see if you can get an official answer. I believe the CRTC regulations prevent them from arbitrarily manipulating, blocking, or shaping the network traffic without disclosing what they are doing.
John
On Fri, Jan 25, 2019 at 4:55 AM Trevor Cordes trevor@tecnopolis.ca wrote:
On 2019-01-25 Trevor Cordes wrote:
Looks like chrony (and others) lets you specify src port, but I'm loathe to uproot the system I know because Bell is braindead. (MTS didn't use to block it, and block-happy Shaw does not block it.)
Epiphany moment: iptables can probably solve this. 20 minutes later:
iptables -t mangle -A OUTPUT -o $iext -p udp --sport 123 --dport 123 -j MARK --set-mark 30 iptables -t nat -A POSTROUTING -p udp -m mark --mark 30 -j SNAT --to-source :60000-61000
Works perfectly! ntpd now syncs with peers. ntpdate doesn't need -u. I don't need to switch to chrony. And I don't need to wait for ntpd to add this feature*. Go take a hike Bell!!!
*http://bugs.ntp.org/show_bug.cgi?id=1109 ... looks like never
Note, it could be just 1 rule, but I used 2 to make sure that I only SNAT packets originating from within the actual firewall/router itself, and not packets being forwarded from within the internal LAN (PC's). I can't figure out a way to specify "really originated locally" other than with mark, but I'm open to ideas. It's not as easy as it sounds with multiple interfaces on the box, unless there's a trick I'm missing.
If I wanted internal LAN PCs to also have their traffic go through, I'd need to use a -j MASQUERADE (it's a dynamic IP) in an extra rule and change the syntax slightly. Since all internal PCs should be set to use the firewall as ntp server, this shouldn't be a problem (in fact could help me id broken PC ntp setups). _______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
Likely they're trying to block NTP amplification attacks, https://www.incapsula.com/ddos/attack-glossary/ntp-amplification.html , and they went overboard on the firewall rule.
On Fri, Jan 25, 2019 at 8:51 AM John Lange john@johnlange.ca wrote:
One of my favorite sayings is "never suspect a conspiracy, that which can be explained by incompetence". This is likely an accidental side effect of something else they've done because unless they are now trying to sell you some kind of Bell branded time-sync service, I can't think of any business reason why they would do this intentionally.
Although, one thing I can think of is, perhaps there is a whole lot of unsecured NTP on their network being actively exploited?
Might be worth going through the pain of opening a ticket to see if you can get an official answer. I believe the CRTC regulations prevent them from arbitrarily manipulating, blocking, or shaping the network traffic without disclosing what they are doing.
John
On Fri, Jan 25, 2019 at 4:55 AM Trevor Cordes trevor@tecnopolis.ca wrote:
On 2019-01-25 Trevor Cordes wrote:
Looks like chrony (and others) lets you specify src port, but I'm loathe to uproot the system I know because Bell is braindead. (MTS didn't use to block it, and block-happy Shaw does not block it.)
Epiphany moment: iptables can probably solve this. 20 minutes later:
iptables -t mangle -A OUTPUT -o $iext -p udp --sport 123 --dport 123 -j MARK --set-mark 30 iptables -t nat -A POSTROUTING -p udp -m mark --mark 30 -j SNAT --to-source :60000-61000
Works perfectly! ntpd now syncs with peers. ntpdate doesn't need -u. I don't need to switch to chrony. And I don't need to wait for ntpd to add this feature*. Go take a hike Bell!!!
*http://bugs.ntp.org/show_bug.cgi?id=1109 ... looks like never
Note, it could be just 1 rule, but I used 2 to make sure that I only SNAT packets originating from within the actual firewall/router itself, and not packets being forwarded from within the internal LAN (PC's). I can't figure out a way to specify "really originated locally" other than with mark, but I'm open to ideas. It's not as easy as it sounds with multiple interfaces on the box, unless there's a trick I'm missing.
If I wanted internal LAN PCs to also have their traffic go through, I'd need to use a -j MASQUERADE (it's a dynamic IP) in an extra rule and change the syntax slightly. Since all internal PCs should be set to use the firewall as ntp server, this shouldn't be a problem (in fact could help me id broken PC ntp setups). _______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
-- John Lange
Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
Our "high-end" fibre business internet from MTS at work hasn't blocked any NTP traffic. Our internal NTP servers sync out on port 123, and it's all been allowed so far.
-- Wyatt Zacharias
On Fri, Jan 25, 2019 at 8:55 AM Colin Stanners cstanners@gmail.com wrote:
Likely they're trying to block NTP amplification attacks, https://www.incapsula.com/ddos/attack-glossary/ntp-amplification.html , and they went overboard on the firewall rule.
On Fri, Jan 25, 2019 at 8:51 AM John Lange john@johnlange.ca wrote:
One of my favorite sayings is "never suspect a conspiracy, that which can be explained by incompetence". This is likely an accidental side effect of something else they've done because unless they are now trying to sell you some kind of Bell branded time-sync service, I can't think of any business reason why they would do this intentionally.
Although, one thing I can think of is, perhaps there is a whole lot of unsecured NTP on their network being actively exploited?
Might be worth going through the pain of opening a ticket to see if you can get an official answer. I believe the CRTC regulations prevent them from arbitrarily manipulating, blocking, or shaping the network traffic without disclosing what they are doing.
John
On Fri, Jan 25, 2019 at 4:55 AM Trevor Cordes trevor@tecnopolis.ca wrote:
On 2019-01-25 Trevor Cordes wrote:
Looks like chrony (and others) lets you specify src port, but I'm loathe to uproot the system I know because Bell is braindead. (MTS didn't use to block it, and block-happy Shaw does not block it.)
Epiphany moment: iptables can probably solve this. 20 minutes later:
iptables -t mangle -A OUTPUT -o $iext -p udp --sport 123 --dport 123 -j MARK --set-mark 30 iptables -t nat -A POSTROUTING -p udp -m mark --mark 30 -j SNAT --to-source :60000-61000
Works perfectly! ntpd now syncs with peers. ntpdate doesn't need -u. I don't need to switch to chrony. And I don't need to wait for ntpd to add this feature*. Go take a hike Bell!!!
*http://bugs.ntp.org/show_bug.cgi?id=1109 ... looks like never
Note, it could be just 1 rule, but I used 2 to make sure that I only SNAT packets originating from within the actual firewall/router itself, and not packets being forwarded from within the internal LAN (PC's). I can't figure out a way to specify "really originated locally" other than with mark, but I'm open to ideas. It's not as easy as it sounds with multiple interfaces on the box, unless there's a trick I'm missing.
If I wanted internal LAN PCs to also have their traffic go through, I'd need to use a -j MASQUERADE (it's a dynamic IP) in an extra rule and change the syntax slightly. Since all internal PCs should be set to use the firewall as ntp server, this shouldn't be a problem (in fact could help me id broken PC ntp setups). _______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
-- John Lange
Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
I had an issue with NTP port 123 being blocked when switching from MTS's phone-line based ADSL service to their fibre based "VDSL" service several years ago (well before the Bell takeover). Colin is right: they wanted to block NTP amplification attacks and went way overboard. Even after the threat had pretty much passed, they refused to relax that restriction on their home fibre Internet service. Apparently the only solution is to use MTS's own NTP server. I think it's ntp.mts.net, but I'm not at home now so I can neither check my NTP settings, nor verify that it's still working correctly. It's a pain for devices where you can't change the NTP server setting, because there's really no other recourse but to live with inaccurate clocks. At least my phone can sync off of LTE.
On 1/25/19 9:16 AM, Wyatt Zacharias wrote:
Our "high-end" fibre business internet from MTS at work hasn't blocked any NTP traffic. Our internal NTP servers sync out on port 123, and it's all been allowed so far.
-- Wyatt Zacharias
On Fri, Jan 25, 2019 at 8:55 AM Colin Stanners <cstanners@gmail.com mailto:cstanners@gmail.com> wrote:
Likely they're trying to block NTP amplification attacks, https://www.incapsula.com/ddos/attack-glossary/ntp-amplification.html , and they went overboard on the firewall rule. On Fri, Jan 25, 2019 at 8:51 AM John Lange <john@johnlange.ca <mailto:john@johnlange.ca>> wrote: One of my favorite sayings is "never suspect a conspiracy, that which can be explained by incompetence". This is likely an accidental side effect of something else they've done because unless they are now trying to sell you some kind of Bell branded time-sync service, I can't think of any business reason why they would do this intentionally. Although, one thing I can think of is, perhaps there is a whole lot of unsecured NTP on their network being actively exploited? Might be worth going through the pain of opening a ticket to see if you can get an official answer. I believe the CRTC regulations prevent them from arbitrarily manipulating, blocking, or shaping the network traffic without disclosing what they are doing. John On Fri, Jan 25, 2019 at 4:55 AM Trevor Cordes <trevor@tecnopolis.ca <mailto:trevor@tecnopolis.ca>> wrote: On 2019-01-25 Trevor Cordes wrote: > Looks like chrony (and others) lets you specify src port, but I'm > loathe to uproot the system I know because Bell is braindead. (MTS > didn't use to block it, and block-happy Shaw does not block it.) Epiphany moment: iptables can probably solve this. 20 minutes later: iptables -t mangle -A OUTPUT -o $iext -p udp --sport 123 --dport 123 -j MARK --set-mark 30 iptables -t nat -A POSTROUTING -p udp -m mark --mark 30 -j SNAT --to-source :60000-61000 Works perfectly! ntpd now syncs with peers. ntpdate doesn't need -u. I don't need to switch to chrony. And I don't need to wait for ntpd to add this feature*. Go take a hike Bell!!! *http://bugs.ntp.org/show_bug.cgi?id=1109 ... looks like never Note, it could be just 1 rule, but I used 2 to make sure that I only SNAT packets originating from within the actual firewall/router itself, and not packets being forwarded from within the internal LAN (PC's). I can't figure out a way to specify "really originated locally" other than with mark, but I'm open to ideas. It's not as easy as it sounds with multiple interfaces on the box, unless there's a trick I'm missing. If I wanted internal LAN PCs to also have their traffic go through, I'd need to use a -j MASQUERADE (it's a dynamic IP) in an extra rule and change the syntax slightly. Since all internal PCs should be set to use the firewall as ntp server, this shouldn't be a problem (in fact could help me id broken PC ntp setups). _______________________________________________ Roundtable mailing list Roundtable@muug.ca <mailto:Roundtable@muug.ca> https://muug.ca/mailman/listinfo/roundtable -- John Lange _______________________________________________ Roundtable mailing list Roundtable@muug.ca <mailto:Roundtable@muug.ca> https://muug.ca/mailman/listinfo/roundtable _______________________________________________ Roundtable mailing list Roundtable@muug.ca <mailto:Roundtable@muug.ca> https://muug.ca/mailman/listinfo/roundtable
Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
NTP over IPv6 over GRE (i.e. a tunnelbroker.net connection) is not blocked and works perfectly. That's how I worked around it at Avant :-).
-Adam
On 2019-01-25 13:27, Gilles Detillieux wrote:
I had an issue with NTP port 123 being blocked when switching from MTS's phone-line based ADSL service to their fibre based "VDSL" service several years ago (well before the Bell takeover). Colin is right: they wanted to block NTP amplification attacks and went way overboard. Even after the threat had pretty much passed, they refused to relax that restriction on their home fibre Internet service. Apparently the only solution is to use MTS's own NTP server. I think it's ntp.mts.net, but I'm not at home now so I can neither check my NTP settings, nor verify that it's still working correctly. It's a pain for devices where you can't change the NTP server setting, because there's really no other recourse but to live with inaccurate clocks. At least my phone can sync off of LTE.
On 1/25/19 9:16 AM, Wyatt Zacharias wrote: Our "high-end" fibre business internet from MTS at work hasn't blocked any NTP traffic. Our internal NTP servers sync out on port 123, and it's all been allowed so far.
-- Wyatt Zacharias
On Fri, Jan 25, 2019 at 8:55 AM Colin Stanners cstanners@gmail.com wrote:
Likely they're trying to block NTP amplification attacks, https://www.incapsula.com/ddos/attack-glossary/ntp-amplification.html , and they went overboard on the firewall rule.
On Fri, Jan 25, 2019 at 8:51 AM John Lange john@johnlange.ca wrote: One of my favorite sayings is "never suspect a conspiracy, that which can be explained by incompetence". This is likely an accidental side effect of something else they've done because unless they are now trying to sell you some kind of Bell branded time-sync service, I can't think of any business reason why they would do this intentionally.
Although, one thing I can think of is, perhaps there is a whole lot of unsecured NTP on their network being actively exploited?
Might be worth going through the pain of opening a ticket to see if you can get an official answer. I believe the CRTC regulations prevent them from arbitrarily manipulating, blocking, or shaping the network traffic without disclosing what they are doing.
John
On Fri, Jan 25, 2019 at 4:55 AM Trevor Cordes trevor@tecnopolis.ca wrote: On 2019-01-25 Trevor Cordes wrote:
Looks like chrony (and others) lets you specify src port, but I'm loathe to uproot the system I know because Bell is braindead. (MTS didn't use to block it, and block-happy Shaw does not block it.)
Epiphany moment: iptables can probably solve this. 20 minutes later:
iptables -t mangle -A OUTPUT -o $iext -p udp --sport 123 --dport 123 -j MARK --set-mark 30 iptables -t nat -A POSTROUTING -p udp -m mark --mark 30 -j SNAT --to-source :60000-61000
Works perfectly! ntpd now syncs with peers. ntpdate doesn't need -u. I don't need to switch to chrony. And I don't need to wait for ntpd to add this feature*. Go take a hike Bell!!!
*http://bugs.ntp.org/show_bug.cgi?id=1109 ... looks like never
Note, it could be just 1 rule, but I used 2 to make sure that I only SNAT packets originating from within the actual firewall/router itself, and not packets being forwarded from within the internal LAN (PC's). I can't figure out a way to specify "really originated locally" other than with mark, but I'm open to ideas. It's not as easy as it sounds with multiple interfaces on the box, unless there's a trick I'm missing.
If I wanted internal LAN PCs to also have their traffic go through, I'd need to use a -j MASQUERADE (it's a dynamic IP) in an extra rule and change the syntax slightly. Since all internal PCs should be set to use the firewall as ntp server, this shouldn't be a problem (in fact could help me id broken PC ntp setups). _______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable --
John Lange _______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
_______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
_______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
On January 25, 2019 3:36:36 a.m. CST, Trevor Cordes trevor@tecnopolis.ca wrote:
I noticed that at one of the customers I have that uses low-end business MTS has had their NTP incoming/outgoing port (UDP 123) cut off (filtered) at the ISP. Incoming I can understand, but outgoing? All the computers in the office have their time out of sync now.
Does anyone know what the internal Bell/MTS time server's IP/domain is? Surely they didn't cut us off to their internal one.
Will have the customer contact them eventually, but you know how it goes with tech support. Looking for the quick solution...
Anyone else have their UDP 123 cut off since Bell came along?
Further: it looks like they are filtering outgoing only if your source port is also 123. That is hardcoded into ntp (from what I've read). But ntpdate allows the -u option to have the src port be >1024. I tried that and ntpdate -u does work, but ntpdate without the -u gets blocked. So they really are blocking in and out, but only src=123udp.
Looks like chrony (and others) lets you specify src port, but I'm loathe to uproot the system I know because Bell is braindead. (MTS didn't use to block it, and block-happy Shaw does not block it.) _______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
MTS has been blocking NTP for at least 3 years, I think more but can't be certain. They did it when NTP was being exploited as a DDoS vector worldwide. Apparently enough customers had routers/PCs hooked up that were exploitable that it was becoming a serious nuisance. IIRC a handful of "important" NTP servers are whitelisted, e.g. time.windows.com and the equivalent from Apple. The source port limitation is specifically because only full-fledged NTP server implementations were vulnerable, and they must by definition use port 123. The block only exists for ADSL/VDSL/FTTH customers AFAIK. Business fibre and SHDSL customers are expected to run firewalls that work. -Adam
On 2019-01-25 Adam Thompson wrote:
IIRC a handful of "important" NTP servers are whitelisted, e.g. time.windows.com and the equivalent from Apple. The source port
I tried time.windows.com, as a first check no dice. No major ntp server I can think of goes through.
limitation is specifically because only full-fledged NTP server implementations were vulnerable, and they must by definition use port 123. The block only exists for ADSL/VDSL/FTTH customers AFAIK. Business fibre and SHDSL customers are expected to run firewalls that work. -Adam
The customer is VDSL business, low-ish end plan, but not fibre. Yes, one would think they'd not block 123 for business. This plan does *not* block SMTP port 25. What a strange world MTS dwells in that 25 is open but 123 is not.
On 2019-01-25 John Lange wrote:
Might be worth going through the pain of opening a ticket to see if you can get an official answer. I believe the CRTC regulations prevent them from arbitrarily manipulating, blocking, or shaping the network traffic without disclosing what they are doing.
The staff will contact MTS so we'll see. I did find a web page that showed all the ports MTS blocks, and 123 wasn't on there. Probably out of date though (still said MTS). As for ISP companies not blocking without disclosing... wouldn't hold my breath on that one.
On 2019-01-25 Gilles Detillieux wrote:
I had an issue with NTP port 123 being blocked when switching from MTS's phone-line based ADSL service to their fibre based "VDSL" service several years ago (well before the Bell takeover). Colin is
Ah, that might be it! It may not have broken when Bell took over, it may have broken when the company switched to VDSL. It was around the same time I think (give or take 2 years, grin). Weird I didn't notice until now... I guess the RTCs were so good it took this long to lose a whole 1-2 minutes and cause me to notice.
Apparently the only solution is to use MTS's own NTP server. I think it's ntp.mts.net, but I'm not at home now so I can neither check my
ntp.mts.net also does not work. If you do have their official ntp server name somewhere, please dig it up for me as that would be super handy if they decide to block my current workaround trick too!
Thanks all!
On my MTS home fibre connection, my Windows 10 PC fails to synchronize to the two MS defaults, time.windows.com and time.nist.gov. ntp.mts.net does work for me, and also to my surprise, so does 0.pool.ntp.org. My PC was able to sync to these two multiple times. I'm pretty sure when I tried this previously a few years ago, the latter one wasn't reachable, but they may have added a whitelist for it because it's such a common built-in one for many devices. I haven't tried any other subdomains of ntp.org so I don't know how thoroughly they whitelisted.
On 2019-01-26 02:44, Trevor Cordes wrote:
On 2019-01-25 Adam Thompson wrote:
IIRC a handful of "important" NTP servers are whitelisted, e.g. time.windows.com and the equivalent from Apple. The source port
I tried time.windows.com, as a first check no dice. No major ntp server I can think of goes through.
limitation is specifically because only full-fledged NTP server implementations were vulnerable, and they must by definition use port 123. The block only exists for ADSL/VDSL/FTTH customers AFAIK. Business fibre and SHDSL customers are expected to run firewalls that work. -Adam
The customer is VDSL business, low-ish end plan, but not fibre. Yes, one would think they'd not block 123 for business. This plan does *not* block SMTP port 25. What a strange world MTS dwells in that 25 is open but 123 is not.
On 2019-01-25 John Lange wrote:
Might be worth going through the pain of opening a ticket to see if you can get an official answer. I believe the CRTC regulations prevent them from arbitrarily manipulating, blocking, or shaping the network traffic without disclosing what they are doing.
The staff will contact MTS so we'll see. I did find a web page that showed all the ports MTS blocks, and 123 wasn't on there. Probably out of date though (still said MTS). As for ISP companies not blocking without disclosing... wouldn't hold my breath on that one.
On 2019-01-25 Gilles Detillieux wrote:
I had an issue with NTP port 123 being blocked when switching from MTS's phone-line based ADSL service to their fibre based "VDSL" service several years ago (well before the Bell takeover). Colin is
Ah, that might be it! It may not have broken when Bell took over, it may have broken when the company switched to VDSL. It was around the same time I think (give or take 2 years, grin). Weird I didn't notice until now... I guess the RTCs were so good it took this long to lose a whole 1-2 minutes and cause me to notice.
Apparently the only solution is to use MTS's own NTP server. I think it's ntp.mts.net, but I'm not at home now so I can neither check my
ntp.mts.net also does not work. If you do have their official ntp server name somewhere, please dig it up for me as that would be super handy if they decide to block my current workaround trick too!
Thanks all! _______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
On 2019-01-26 Gilles Detillieux wrote:
On my MTS home fibre connection, my Windows 10 PC fails to synchronize to the two MS defaults, time.windows.com and time.nist.gov. ntp.mts.net does work for me, and also to my surprise, so does 0.pool.ntp.org.
Just tested, all above are blocked for me. Weird that the 0.pool works for you since that's just a DNS load-balancing placeholder, meaning it will return different IP addresses each time. For MTS to poke a hole for such a thing probably would be quite tricky.
Note: looks like the surest test is to stop ntpd and run ntpdate foo.com then ntpdate -u foo.com. The -u should always work. The non-u will fail if filtering is being done and you don't have workarounds in place.
Looks like (big surprise) MTS & Bell are fragmented in terms of what they block depending on whether you are home/business and/or dsl/vdsl/fibre.
(Have I ever mentioned I hate MTS?) ;-)
-
Adam Thompson -
Colin Stanners -
Gilles Detillieux -
John Lange -
Trevor Cordes -
Wyatt Zacharias