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

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

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

L6 Presenter

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

1 accepted solution

Accepted Solutions

Community Team Member

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

LIVEcommunity team member, CISSP
Cheers,
Kiwi
Please help out other users and “Accept as Solution” if a post helps solve your problem !

Read more about how and why to accept solutions.

View solution in original post

7 REPLIES 7

Community Team Member

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

LIVEcommunity team member, CISSP
Cheers,
Kiwi
Please help out other users and “Accept as Solution” if a post helps solve your problem !

Read more about how and why to accept solutions.

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




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

Thanks all. Still looking into this 

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 

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?

L0 Member

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. 

  • 1 accepted solution
  • 12608 Views
  • 7 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!