[Linux-aus] internode/iinet/tpg ipv4 bogons in route
paul-linuxaus at gear.email
Thu Jun 16 07:04:48 AEST 2022
It's also very common for a traceroute not to match in both directions,
because the ICMP time exceeded messages come from the address of the
interface facing the source IP, and a router will usually have different
IP addresses on multiple interfaces. (The data can also take a
completely different path, often depending on economic arrangements
between the parties involved.)
For example, here are some of the hops between my router and
route-views.routeviews.org (in Oregon). It looks like
TPG-iiNet-Internode peers with Hurricane Electric in San Jose, and it
traverses the same ISP in both directions, but look at the addresses on
the border between those two networks.
4.|-- adl-ts3-2600-106.tpgi.com.au (188.8.131.52)
0.0% 10 18.2 18.4 18.0 18.9 0.3
5.|-- syd-apt-ros-int1-eth8-3.tpgi.com.au (184.108.40.206)
0.0% 10 19.8 21.4 18.4 25.5 2.6
6.|-- 100gigabitethernet13-1.core1.sjc1.he.net (220.127.116.11)
0.0% 10 172.6 172.3 171.7 173.4 0.5
7.|-- 100ge1-1.core1.sjc2.he.net (18.104.22.168)
0.0% 10 173.6 172.6 172.1 173.6 0.5
Inbound (looks different because route-views runs Cisco IOS-XE and it
has traceroute, not mtr):
13 100ge1-2.core1.pao1.he.net (22.214.171.124) [AS 6939] 16 msec
100ge10-1.core1.sjc1.he.net (126.96.36.199) [AS 6939] 16 msec 17 msec
(188.8.131.52) [AS 6939] 178 msec 175 msec
100ge10-1.core1.sjc1.he.net (184.108.40.206) [AS 6939] 16 msec
(220.127.116.11) [AS 6939] 175 msec 175 msec 176 msec
16 syd-sot-ken-csw1-ge-2-23.tpgi.com.au (18.104.22.168) [AS 7545]
[MPLS: Label 24446 Exp 0] 184 msec
syd-apt-ros-crt4-be-100.tpgi.com.au (22.214.171.124) [AS 7545] 172 msec
syd-sot-ken-csw1-ge-2-23.tpgi.com.au (126.96.36.199) [AS 7545]
[MPLS: Label 24446 Exp 0] 184 msec
188.8.131.52 and 184.108.40.206 are probably the two ends of TPG's
point-to-point connection to Hurricane Electric which is probably the
network 220.127.116.11/30, but we only see one of the IPs in each
direction. (The /30 is just a guess, but it's not a /31, because they
must start on the even-numbered address, and I get timeouts when pinging
18.104.22.168 and 22.214.171.124, so it seems a reasonable guess.)
On 15/6/22 23:33, dap at zepherin.com wrote:
> I am sure I'm not blocking the ping at my (UDM Pro) firewall, but the Fritz!box also has a firewall.
> Because I see the weird 10.20.21.212 hop outbound, I assumed I would see it on inbound, and thus it appeared to be the next hop to fix.
> However, no small amount of dorking about with the Fritz!Box has resulted in me figuring out that I need to designate the UDM as "exposed host".
> I know I should have more faith in the Unifi firewall, and I should have been happy to put the UDM into the DMZ, but I always felt marginally less insecure leaving it so that the mystical, inaccessible Fritz!box firewall was also preventing rogue SYNs from molesting my sockets.
> Once I enable "Exposed Host" on the Fritz, pings work, and "mtr" is able to reveal to me that there is no 10.20.21.212 hop inbound. Just outbound.
> The bogon hop still annoys me -- perhaps I need to get a life.
> Sent with Proton Mail secure email.
> ------- Original Message -------
> On Wednesday, June 15th, 2022 at 15:10, Paul Gear via linux-aus <linux-aus at lists.linux.org.au> wrote:
>> The existence of that node on the path should not break mtr - it should
>> continue trying increased TTLs until it gets to the end node.
>> Are you sure you're not blocking ping at your firewall?
>> On 15/6/22 14:35, Damon Permezel via linux-aus wrote:
>>> Breaks mtr.
>>> Im trying to diagnose some issues and the other party insists on mtr
>>> working from both sides.
>>> Inbound to me the 10.20.21.212 drops all pings and mtr goes no further.
>>> The ping is not addressed to 10.20.21.212. It should elicit a ttl
>>> expired icmp response.
More information about the linux-aus