WAN link MAC address replaces modem MAC preventing me from accessing modem confi

[aida]

I have a VDSL connection, and my modem is in bridge mode. The connection is IPOE/DHCP (so no PPP connection). I've found that when I connect the WAN link a MAC address shows up 00:a2:00:b2:00:c2 for that link. I think it's some kind of virtual MAC of whatever is on the other end of my WAN link as it has no proper OUI.

The issue I'm having is I'm trying to NAT to my mode, ie pass through to be able to reach the modem config. This works when the ARP table entry shows the MAC address of my modem, periodically though it changes:

Code: [Select]

? (192.168.0.1) at 00:a2:00:b2:00:c2 on igb3 expires in 1000 seconds [ethernet]
If I manually set the entry with:

Code: [Select]

# arp -S 192.168.0.1 <modem's real MAC>
I can access my modem again, until the next time it is replaced.

The NAT rule I have is currently:

Code: [Select]

nat on igb3 inet from ! 192.168.0.2 to 192.168.0.1 -> 192.168.0.2 port 1024:65535
My WAN link is:

Code: [Select]

igb3: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: WAN
options=4800028<VLAN_MTU,JUMBO_MTU,NOMAP>
ether xx:xx:xx:xx:xx:xx
inet6 fe80::xxxx:xxxx:xxxx:xxxx%igb3 prefixlen 64 scopeid 0x4
inet6 xxx:xxx:xxx:xxx:1::1 prefixlen 128
inet xx.xx.xx.xxx netmask 0xffffff00 broadcast xxx.xxx.xx.xxx
inet 192.168.0.2 netmask 0xfffffff8 broadcast 192.168.0.7
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
Obviously running that arp command and replacing the entry isn't ideal because I will have to do this periodically. I have a tool on my server which logs in via telnet and parses line sync stats into a graph so I need this to be unattended.

[lilsense]

If you login to the modem, all the interfaces should have a specific MAC address. Some modems actually have the MAC label on the box outside. This MAC address should be reachable in bridge mode. You should be able to use the same ARP command but using the permanent MAC address as opposed to the virtual one.

[aida]

You should be able to use the same ARP command but using the permanent MAC address as opposed to the virtual one.

Yes I was using the -S option to delete existing ARP the existing arp entry for that host and replace it with a manual one. The issue is that periodically that entry is replaced by 00:a2:00:b2:00:c2 regardless of whether or not I make a permanent entry over the top. 00:a2:00:b2:00:c2 appears to be the MAC address of whatever device is at the other end of my VDSL link. What is interesting is I don't remember this happening with dhcpcd on Linux.

Perhaps it had something to do with ARP entries only being allowed once during dhcpcd initialization or something. This is what the log looked like during initialization of the WAN interface:

Code: [Select]

gateway:~# dhcpcd -z eth1
no such user dhcpcd
dhcpcd-9.4.1 starting
spawned manager process on PID 3128
DUID 00:01:00:01:2a:02:5b:c5:80:49:71:12:38:79
eth1: executing: /usr/lib/dhcpcd/dhcpcd-run-hooks PREINIT
eth1: executing: /usr/lib/dhcpcd/dhcpcd-run-hooks CARRIER
eth1: IAID 00:00:00:01
eth1: delaying IPv6 router solicitation for 0.5 seconds
dhcp6_openudp: Address in use
dhcp6_start1: Address in use
eth1: delaying IPv4 for 1.6 seconds
eth1: soliciting an IPv6 router
eth1: sending Router Solicitation
eth1: Router Advertisement from fe80::c225:e9ff:feac:19d8
eth1: executing: /usr/lib/dhcpcd/dhcpcd-run-hooks ROUTERADVERT
dhcp6_openudp: Address in use
dhcp6_start1: Address in use
eth1: Router Advertisement from fe80::2a2:ff:feb2:c2
eth1: adding default route via fe80::2a2:ff:feb2:c2
eth1: executing: /usr/lib/dhcpcd/dhcpcd-run-hooks ROUTERADVERT
dhcp6_openudp: Address in use
dhcp6_start1: Address in use
eth1: reading lease: /var/lib/dhcpcd/eth1.lease
eth1: rebinding lease of 203.123.107.93
eth1: ARP announcing 203.123.107.93 (1 of 2), next in 2.0 seconds
eth1: sending REQUEST (xid 0xe2812515), next in 3.6 seconds
eth1: acknowledged 203.123.107.93 from 202.65.94.1
eth1: leased 203.123.107.93 for 600 seconds
eth1: renew in 300 seconds, rebind in 525 seconds
eth1: writing lease: /var/lib/dhcpcd/eth1.lease
eth1: adding IP address 203.123.107.93/24 broadcast 203.123.107.255
eth1: adding route to 203.123.107.0/24
eth1: adding default route via 203.123.107.1
eth1: ARP announcing 203.123.107.93 (1 of 2), next in 2.0 seconds
eth1: executing: /usr/lib/dhcpcd/dhcpcd-run-hooks REBOOT
waiting for an IPv6 address
eth1: ARP announcing 203.123.107.93 (2 of 2)
eth1: Router Advertisement from fe80::c225:e9ff:feac:19d8
eth1: executing: /usr/lib/dhcpcd/dhcpcd-run-hooks ROUTERADVERT
eth1: Router Advertisement from fe80::c225:e9ff:feac:19d8
eth1: executing: /usr/lib/dhcpcd/dhcpcd-run-hooks ROUTERADVERT
eth1: Router Advertisement from fe80::c225:e9ff:feac:19d8
eth1: executing: /usr/lib/dhcpcd/dhcpcd-run-hooks ROUTERADVERT
eth1: Router Advertisement from fe80::c225:e9ff:feac:19d8
eth1: executing: /usr/lib/dhcpcd/dhcpcd-run-hooks ROUTERADVERT
eth1: Router Advertisement from fe80::c225:e9ff:feac:19d8
eth1: executing: /usr/lib/dhcpcd/dhcpcd-run-hooks ROUTERADVERT
 * Stopping chronyd ... [ ok ]
 * Starting chronyd ... [ ok ]
timed out
forked to background, child pid 3128

[lilsense]

OK. I am kind of confused of this purpose... I see no reason to continuously connecting to the VDSL modem which is set to bridge mode for management. It's typically set and forgotten about it, unless it's got tons of problems which then is replaced with better modem or a different ISP.

[aida]

I see no reason to continuously connecting to the VDSL modem which is set to bridge mode for management.

The purpose is to keep periodic metrics on the line sync stats. Makes it easier to raise an issue if a line fault on the line occurs.

It's typically set and forgotten about it, unless it's got tons of problems which then is replaced with better modem or a different ISP.

A better or new modem or different ISP isn't going to improve the quality of last mile cable. It's why if you're smart you don't build broadband networks with copper. Sadly these decisions are not within a subscriber's control in some cases.

Anyway the strange thing is that this particular MAC address 00:a2:00:b2:00:c2 from the WAN link seems to replace the local one on my modem's local IP address in the ARP table. I'm thinking my only solution to this might be to use a modem that supports openwrt and allows for vlan tagging and binding of the management interface to that. The Lantiq/Intel/Max Linear VRX518 chipset may soon be supported although I don't fancy having to compile openwrt builds myself. I guess the alternative would be an expensive ISR like the Cisco C1117.

I checked with both TP-Link and AVM regarding the FRITZ!Box and these do not allow for static routes to a specific interface or port with the OEM firmware. You can only specify the route to all the LAN ports.

[Maurice]

Oh, the joys of NBN...

Code: [Select]

eth1: Router Advertisement from fe80::2a2:ff:feb2:c2
eth1: adding default route via fe80::2a2:ff:feb2:c2


00:a2:00:b2:00:c2 is most likely the upstream router. It might reply to all ARP requests with its own MAC address. You can verify this by pinging a random IPv4 address within the WAN subnets (like 192.168.0.3) and check whether it shows up in the ARP table.

This alone wouldn't be an issue, but it seems your modem forwards ARP requests upstream even if they're for its own IP address. Replacing the modem may indeed fix this. I've been using the basic Draytek modems (Vigor 130) in the past and they were quite reliable.

Cheers
Maurice

[aida]

Oh, the joys of NBN...

Code: [Select]

eth1: Router Advertisement from fe80::2a2:ff:feb2:c2
eth1: adding default route via fe80::2a2:ff:feb2:c2


_{00:a2:00:b2:00:c2} is most likely the upstream router. It might reply to all ARP requests with its own MAC address. You can verify this by pinging a random IPv4 address within the WAN subnets (like 192.168.0.3) and check whether it shows up in the ARP table.

Interesting that indeed does happen:

? (192.168.0.3) at 00:a2:00:b2:00:c2 on igb3 expires in 1116 seconds [ethernet]
? (192.168.0.4) at 00:a2:00:b2:00:c2 on igb3 expires in 1198 seconds [ethernet]
? (192.168.0.5) at 00:a2:00:b2:00:c2 on igb3 expires in 1129 seconds [ethernet]

I saw the same MAC address associated with my global IP when I connected my laptop directly when the mode. On a side note, it's a strange MAC address with no valid OUI. I wonder if they do that to prevent people mapping their hardware or something.

[chemlud]

Oh, the joys of NBN...

Code: [Select]

eth1: Router Advertisement from fe80::2a2:ff:feb2:c2
eth1: adding default route via fe80::2a2:ff:feb2:c2


_{00:a2:00:b2:00:c2} is most likely the upstream router. It might reply to all ARP requests with its own MAC address. You can verify this by pinging a random IPv4 address within the WAN subnets (like 192.168.0.3) and check whether it shows up in the ARP table.

Interesting that indeed does happen:

? (192.168.0.3) at 00:a2:00:b2:00:c2 on igb3 expires in 1116 seconds [ethernet]
? (192.168.0.4) at 00:a2:00:b2:00:c2 on igb3 expires in 1198 seconds [ethernet]
? (192.168.0.5) at 00:a2:00:b2:00:c2 on igb3 expires in 1129 seconds [ethernet]

I saw the same MAC address associated with my global IP when I connected my laptop directly when the mode. On a side note, it's a strange MAC address with no valid OUI. I wonder if they do that to prevent people mapping their hardware or something.

https://www.macvendorlookup.com/search/00:02:A2:00:00:00

and

https://www.hilscher.com/

[aida]

https://www.macvendorlookup.com/search/00:02:A2:00:00:00

and

https://www.hilscher.com/

that's 00:02:A2 as opposed to 00:A2:00. The one I used was https://www.wireshark.org/tools/oui-lookup.html. Anyway pretty sure the DSLAMs, NBNco use are Broadcom BCM65300 and it's not any of those.

[lilsense]

final thought is to include a dummy hub between the Bridge and OPNsense and use the dummy hub MAC address to get to the bridge.