0

Some users of my web server experience a TCP/443-only traffic block. The block is inconsistent across the users' home ISPs, even within a single ISP/city. Seems to be activated by traffic volume. Block lifted on the old IP when I direct traffic to a different IP, new IP is blocked.

All these traceroute methods work: ICMP, UDP, TCP/non-443-port.

Only TCP/443 traceroute fails, right on the 2nd hop (the next router after the home router does not respond).

The question:

  • does this indicate some blacklist being pushed up to the home ISP? If so, what protocol/technology might be used to block traffic so specifically (TCP/443 only) and so early (home ISP in a different country)?
  • or is this related to how TCP traceroute works?
mtr                   <host>   // Full trace
mtr --tcp --port 80   <host>   // Full trace
mtr --tcp --port 666  <host>   // Full trace (except the host), even to a closed port
mtr --tcp --port 443  <host>   // Only home route responds (1 hop), no further hops

(I have contacted all the ASes along the route, nobody acknowledges any traffic blocking so far. So the question is specifically about traceroute and possible mechanisms of such traffic blocking.)

Andrey Moiseev
  • 3,914
  • 7
  • 48
  • 64

1 Answers1

1

This might be caused by traffic to your site going through some sort of middlebox that blocks port 443. There's a wide variety of equipment capable of doing this sort of thing for lawful interception/censorship/quality-of-service/security/etc.

It's perfectly plausible for traffic to a specific range of IPs and ports to get "special treatment" from an ISP for either technical or legal reasons.

It's not related to how TCP traceroute works although there could be more benign explanations for what you're seeing (e.g. routers not returning ICMP TTL Expired packets for port 443 due to some sort of bug).

Consider asking on network engineering.

Malt
  • 28,965
  • 9
  • 65
  • 105