Pinging Palo sub-interface reply goes to 00:70:76:69:66:00 as a destination MAC.

[TranceforLife]

Hello All,

l was thinking that this might be an interesting one. Any comments more than welcome 🙂

PAN-OS 7.1.10 PA-5060

635     66.604593       10.13.178.246   10.13.128.1     ICMP    394     Echo (ping) request  id=0x0029, seq=0/0, ttl=64 (reply in 636)

Ethernet II, Src: Apple_7e:b6:ff (38:ca:da:7e:b6:ff), Dst: PaloAlto_00:01:27 (00:1b:17:yy:yy:yy)
    Destination: PaloAlto_00:01:27 (00:1b:17:yy:yy:yy)
    Source: Apple_7e:b6:ff (38:ca:da:7e:b6:ff)
    Type: 802.1Q Virtual LAN (0x8100)

636     66.604754       10.13.128.1     10.13.178.246   ICMP    394     Echo (ping) reply    id=0x0029, seq=0/0, ttl=64 (request in 635)

Ethernet II, Src: PaloAlto_00:01:27 (00:1b:17:00:01:27), Dst: 00:70:76:69:66:00 (00:70:76:69:66:00)
    Destination: 00:70:76:69:66:00 (00:70:76:69:66:00)
    Source: PaloAlto_00:01:27 (00:1b:17:yy:yy:yy)
    Type: 802.1Q Virtual LAN (0x8100)

> debug dataplane internal vif address

1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/24 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
    link/ether y:fe brd ff:ff:ff:ff:ff:ff
3: eth5: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
    link/ether y:ff brd ff:ff:ff:ff:ff:ff
4: eth3: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc mq qlen 1000
    link/ether y:ff brd ff:ff:ff:ff:ff:ff
    inet6 fe80::270:76ff:fe69:66ff/64 scope link
       valid_lft forever preferred_lft forever
5: eth2: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc mq qlen 1000
    link/ether y:fd brd ff:ff:ff:ff:ff:ff
    inet 127.1.1.1/24 brd 127.1.1.255 scope host eth2
    inet6 fe80::290:bff:fe2d:1fd/64 scope link
       valid_lft forever preferred_lft forever
6: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether y:fb brd ff:ff:ff:ff:ff:ff
    inet 192.168.xx.x/29 brd 192.168.xx.xscope global eth1
    inet6 fe80::290:bff:fe2d:1fb/64 scope link
       valid_lft forever preferred_lft forever
7: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether y:fa brd ff:ff:ff:ff:ff:ff
    inet 172.27.xx.x/24 brd 172.27.xx.x scope global eth0
    inet6 fe80::290:bff:fe2d:1fa/64 scope link
       valid_lft forever preferred_lft forever
8: eth3.251@eth3: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue
    link/ether y:ff brd ff:ff:ff:ff:ff:ff
    inet 127.131.1.1/16 scope host eth3.251
    inet 127.132.1.1/16 scope host eth3.251
    inet6 ::ffff:127.131.1.1/112 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::270:76ff:fe69:66ff/64 scope link
       valid_lft forever preferred_lft forever
9: eth3.1@eth3: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue
    link/ether y:ff brd ff:ff:ff:ff:ff:ff
    inet 127.130.1.1/16 scope host eth3.1
    inet 10.13.0.1/17 scope global eth3.1
    inet 10.13.128.1/18 scope global eth3.1

Thx,

Myky

[kiwi · Accepted solution]

Hi @TranceforLife,

00:70:76:69:66:00 is the Palo Alto Firewall internal MAC address.

Only as root you can find it like this example (note that only support can enter as root) :

root@PA--5020 /]# arp -a 
? (192.168.11.110) at 00:70:76:69:66:00 [ether] on eth3.1 
? (127.9.1.240) at 00:70:76:69:66:00 [ether] PERM on eth3.1 
? (127.11.1.240) at 00:70:76:69:66:00 [ether] PERM on eth3.251

It is not unexpected behavior that the internal MAC address shows up in debugs.

Cheers !

-Kiwi

[TranceforLife]

Hello @kiwi,

Thank you for your response. So in the debug it is expected behaviour to see this MAC?

Should l run just simple PCAP on FW to confirm correct MAC address mapping or PCAP will also show the same output?

Thx,

Myky

[BPry]

---

@kiwi wrote:
 

It is not unexpected behavior that the internal MAC address shows up in debugs.

Cheers !

-Kiwi

---

@TranceforLife,

No it wouldn't be expected to see that MAC show up on anything that you have access to without root access, which you wouldn't have access to unless you were running some very old early releases of PANos where this password sometimes got out into the wild. 

The MAC that you recieve should be the MAC Address that you can view right on the GUI in your interfaces tab, the internal firewall MAC shouldn't come up on anything. 

[TranceforLife]

Thanks all. Still looking into this 

[OneAmongMany]

Hi Folks

I stumbled upon this article, as while analysing a PCAP for a download issue, I see the next-hop MAC as 00:70:76:69:66:00....

You've mentioned its an internal MAC; in my case we have a service route configured, but the source IP is still that of the managment interface, so I'm guessing I'm seeing it as its the managment interface (and its MAC), passing to the internal MAC.

The return path in my case (Receive PCAP) I see coming from a Checkpoint appliance  to the MAC of the Data-Plane interface used in the service route. 

Just though I'd share in the hope it helps explain why you might be seeing 0:70:76:69:66:00. 

Thanks

Alex 

[LCMember4723]

I'm seeing this Mac in a PCAP I did on the firewall receive filter while debugging a IP Frag issue where in the ISAKMP packets are being fragmented while performing certificate auth on the IKE gateway. Its causing the IP Frag option to be hit in the Zone protection setting and the IKE v2 setup to fail. Should I assume this is the expected dst mac since this is hitting the zone protection and being forwarded to an internal MAC to be dropped?

[RM7000]

Hello all,

The explanantion makes sense. I ran into the same question regarding this destination MAC Address 00:70:76:69:66:00 when I did a packet capture in Firewall Stage. However, when I check the Transmit Stage of the packet capture, I see the correct destination MAC Address.