Is this provider behavior normal?

Question

System administration

It doesn’t pull on an article on Habré, so I’ll ask here about the situation.

The question is: "Is this normal?"

I set up a laptop with Wi-Fi turned on, the network was free. It so happened that it was necessary to set up a network printer "quickly". Not a question, I put the local address on the laptop and then on the printer. According to the tradition that has developed for a long time, before assigning an address, I ping them. The address just took randomly out of my head, without hesitation - 192.168.40.41 and I wanted to make 192.168.40.40 for the printer.
But then the magic went on, I pinged the address 192.168.40.41 from the laptop and he answered, although this cannot be. I don't have a 40 network, let alone this address. Next, the tracer went into business.

tracert 192.168.40.41
Трассировка маршрута к 192.168.40.41 с максимальным числом прыжков 30
 
  1    <1 мс    <1 мс    <1 мс  192.168.2.250
  2    <1 мс    <1 мс    <1 мс  192.168.1.1
  3     4 ms     4 ms     4 ms  73.*****.donpac.ru [73.*****]
  4     4 ms     4 ms     4 ms  188.***.172
  5    43 ms    37 ms    37 ms  192.168.40.41

The curious reader will immediately see which provider owns the addresses.

My second logical action is a call to the TP of this provider to clarify why I see someone's address on my network. The answer was:

It is from a private network, it is not detected on our equipment, it does not resolve through 2IP and similar services. The problem is with your hardware.

If you do not take into account the fact that the TP for some reason punched the address 192.168.40.41 on the external 2ip service, to my quite logical (as I think) question: And here is my equipment, if in the third step your gateway redirected my request first to another equipment (also from this provider), and then to the final address, which you don’t understand where it is, another answer followed:

But somehow this equipment with this IP address was displayed in your monitoring.

From our side, the “Internet Access” service is provided under the contract
Accordingly, the routing of our equipment does not discard steps during tracing and allows ping
. if IP 192.168.40.41 belongs to your internal network

And this IP is quite possible you can ping if the equipment to which it belongs is accessible from the external network
If you want to further protect your network from suspected unauthorized connection from this address - we can offer you additional set up an Access-list on your equipment and prohibit any traffic on any ports with IP 192.168.40.41

Those. Rostelecom turns out (sorry for the spoiler), there are no restrictions at all in their network, and the fact that I ping someone's address of equipment that is plugged into a switch in another city is in the order of things. They have neither vlan nor any other access delimiters for different organizations or trite network segments.
And the problem appears is treated on my party by means of ACL.

Is this normal and am I missing something?

Answer 1

Practically the first step for me was to block any traffic from RFC1918-compliant addresses from the external interface and block it in the same way from internal addresses if it goes to the external interface.
Judging by the drop counter, about 100 MB of such packets were dropped :) And my head doesn't hurt. Yes, there may be crooked users and no less crooked providers - but that's none of my business.

Answer 2

No, this is a clear violation of the RFC.
The address 192.168.40.40 is classified as non-routable on the Internet. Any node, if it received a packet to this address on an interface with a routable address, or if it must, according to its routing table, send it through an interface with a routable address, must refuse routing (which rule to apply - deny or drop - is not described). ). There is an address 188.***.172 in the trail that does not belong to any non-routable network - hence the packet's routing should have been denied.
And what a mess - yes, it's in the order of things. You sniff your external address and see how much "dirt" gets on it - you will be surprised.

Answer 3

In fact, the icmp response, which will contain a "gray" ip address, can arrive from any intermediate node during tracing, and not just from the nearest router or from the network of your provider. This is due to the fact that the ip address in the icmp response that will be displayed in the trace and the actual source address in the ip packet with which it was sent from the transit node are different entities. In addition, the actual source IP address can change from "gray" to "real" on the transit router in order to be guaranteed to be delivered on the Internet. The most common case leading to this is that some intermediate router in the provider's network can process transit traffic with real ip addresses, having only a service gray ip address. Routing protocols quite allow this. So this is basically not a problem, although some are embarrassed.
PS In my practice there was a reverse situation. The security guys got to the bottom of a situation where, when tracing inside the intranet of a large organization, one of the intermediate nodes displayed the real ip-address, even if it belongs to this organization. They demanded to explain why the traffic goes through the Internet :)

Answer 4

This is not entirely correct. But arguing with the mouth is still useless.
By the way, you also didn’t take care to protect yourself properly ... why did your gateway allow ping to a gray address through the WAN interface?)

Answer 5

In general, it is not correct to release routing for such subnets into the world. Usually providers wrap this on localhost in their AS.
Why did the answer come? Most likely, this host 188.***.172 uses the address 192.168.40.41 for internal routing such as iBGP, OSPF, or this is its address in the DMZ zone. And some admin gives this route (192.168.40.0) to the world, and the provider lets it through) There are enough Krivoruks)

Answer 6

This is not the norm, but not a problem either.
You are included in the broadband access segment of Rostelecom, and there the presence of gray addresses is the norm. Therefore, on access, traffic to gray IPs is not limited, it flies somewhere to the core, and somewhere it can even find its recipient.

Answer 7

If you have a router on the edge of the network - just exclude address translation / routing in the Bogoon subnet through the provider's interface.
Inadequate engineers of providers, in recent times, more than we would like, it's a fact. But it's not very scary. You can decide on your own.
Create ACLs or write them explicitly (depending on what you have on the border)