Jump to content

Are there problems with ISPs not dropping RFC1918

mtz_federico
Go to solution Solved by mynameisjuan,
Just now, mtz_federico said:

ok, that makes sense.

Weird thing is that the last response is always from the same ISP that is not mine. 

Which makes sense. Traceroute will keep incrementing by 1 until it reaches its destination. Depending on what you are running a traceroute to you will maybe cross 2-3 even 6 providers. Eventually you will run into *timeout* which just mean you reached a device that doesnt respond to ICMP 

Out of curiosity I just ran a traceroute to the ip addresses 192.169.15.4 and 10.0.3.53 and my isp and some other upstream isps didn't drop the packets traceroute just stopped getting responses.

My question is: Is there any disadvantage to this or any vulnerability that could take advantage of this?

 

RFC1918 is the block of private ip addresses like 192.168.0.1, 10.0.1.3, and 172.16.40.51

Link to comment
Share on other sites

Link to post
Share on other sites

You are just seeing the result of bad design. When you run a traceroute, its just ICMP where the TTL is just incremented each hop. When TTL reaches 0 the packet is dropped and the router created a TTL expired message and sends it back.

 

Interfaces can have multiple IPs and since the response is self generated it will be routed and sent out an interface with its primary IP as the source of the egress interface.

 

There is nothing wrong with it, like I said it is just bad design on any publicly facing interface Public interfaces should always have a global primary. RFC1918 is just reserved space that should not be publicly routable. Well its not publicly routed, you are just getting a response. 

Link to comment
Share on other sites

Link to post
Share on other sites

8 minutes ago, mynameisjuan said:

You are just seeing the result of bad design. When you run a traceroute, its just ICMP where the TTL is just incremented each hop. When TTL reaches 0 the packet is dropped and the router created a TTL expired message and sends it back.

 

Interfaces can have multiple IPs and since the response is self generated it will be routed and sent out an interface with its primary IP as the source of the egress interface.

 

There is nothing wrong with it, like I said it is just bad design on any publicly facing interface Public interfaces should always have a global primary. RFC1918 is just reserved space that should not be publicly routable. Well its not publicly routed, you are just getting a response. 

So the router is dropping the packet (on purpose/a rule or because the router doesn't know where to send it) and that is what I receive?

 

Link to comment
Share on other sites

Link to post
Share on other sites

2 minutes ago, mtz_federico said:

So the router is dropping the packet (on purpose/a rule or because the router doesn't know where to send it) and that is what I receive?

Its dropping a packet due to TTL or Time To Live. Its a mechanism originally made to prevent a packet getting stuck in a loop. Every time a router routes a packet its decreased by 1 and when it reaches 0 its considered dead and drops it and a response is sent back to the sender

Link to comment
Share on other sites

Link to post
Share on other sites

Just now, mynameisjuan said:

Its dropping a packet due to TTL or Time To Live. Its a mechanism originally made to prevent a packet getting stuck in a loop. Every time a router routes a packet its decreased by 1 and when it reaches 0 its considered dead and drops it

ok, that makes sense.

Weird thing is that the last response is always from the same ISP that is not mine. 

Link to comment
Share on other sites

Link to post
Share on other sites

Just now, mtz_federico said:

ok, that makes sense.

Weird thing is that the last response is always from the same ISP that is not mine. 

Which makes sense. Traceroute will keep incrementing by 1 until it reaches its destination. Depending on what you are running a traceroute to you will maybe cross 2-3 even 6 providers. Eventually you will run into *timeout* which just mean you reached a device that doesnt respond to ICMP 

Link to comment
Share on other sites

Link to post
Share on other sites

2 minutes ago, mynameisjuan said:

Which makes sense. Traceroute will keep incrementing by 1 until it reaches its destination. Depending on what you are running a traceroute to you will maybe cross 2-3 even 6 providers. Eventually you will run into *timeout* which just mean you reached a device that doesnt respond to ICMP 

That makes sense. I didn't think of that last part of reaching an upstream provider's router that doesn't respond to ICMP

Link to comment
Share on other sites

Link to post
Share on other sites

I just ran a test using another ISP and the traceroute ends in the same ISP as yesterday

Link to comment
Share on other sites

Link to post
Share on other sites

4 minutes ago, mtz_federico said:

I just ran a test using another ISP and the traceroute ends in the same ISP as yesterday

If you are testing the same IP it's going to almost always end at the same device.

 

I'm just curious what you are testing to

Link to comment
Share on other sites

Link to post
Share on other sites

5 hours ago, mynameisjuan said:

If you are testing the same IP it's going to almost always end at the same device.

 

I'm just curious what you are testing to

No, they are different but they the one that I tested today is in the 192.168.X.X range.

They ISP were the traceroutes have ended is Cogent.

 

I just tested it again because I was bored and was connected to another ISP 

Link to comment
Share on other sites

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×