[Linux-aus] internode/iinet/tpg ipv4 bogons in route

[Paul Gear]

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.

Outbound:

...
   4.|-- adl-ts3-2600-106.tpgi.com.au (203.29.135.106)               
0.0%    10   18.2  18.4  18.0 18.9   0.3
   5.|-- syd-apt-ros-int1-eth8-3.tpgi.com.au (203.29.134.67)         
0.0%    10   19.8  21.4  18.4  25.5   2.6
   6.|-- 100gigabitethernet13-1.core1.sjc1.he.net (216.218.139.233)  
0.0%    10  172.6 172.3 171.7 173.4   0.5
   7.|-- 100ge1-1.core1.sjc2.he.net (184.105.65.114)                 
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 (184.104.195.173) [AS 6939] 16 msec
     100ge10-1.core1.sjc1.he.net (184.105.80.193) [AS 6939] 16 msec 17 msec
  14 tpg-internet-pty-ltd.100gigabitethernet11-1.core1.sjc1.he.net 
(216.218.139.234) [AS 6939] 178 msec 175 msec
     100ge10-1.core1.sjc1.he.net (184.105.80.193) [AS 6939] 16 msec
  15 tpg-internet-pty-ltd.100gigabitethernet11-1.core1.sjc1.he.net 
(216.218.139.234) [AS 6939] 175 msec 175 msec 176 msec
  16 syd-sot-ken-csw1-ge-2-23.tpgi.com.au (203.29.135.109) [AS 7545] 
[MPLS: Label 24446 Exp 0] 184 msec
     syd-apt-ros-crt4-be-100.tpgi.com.au (203.29.134.44) [AS 7545] 172 msec
     syd-sot-ken-csw1-ge-2-23.tpgi.com.au (203.29.135.109) [AS 7545] 
[MPLS: Label 24446 Exp 0] 184 msec
...

216.218.139.233 and 216.218.139.234 are probably the two ends of TPG's 
point-to-point connection to Hurricane Electric which is probably the 
network 216.218.139.232/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 
216.218.139.232 and 216.218.139.235, so it seems a reasonable guess.)

Regards,
Paul

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.
>>>