I have a problem that occured on R80.20. In the end we had to move a VPN, Can someone explain why you can have an ESP and ARP broadcast at the same time?
10:12:10.207381 00:12:c1:ce:90:08 ^ Broadcast, ethertype IPv4 (0x0800), length 134: x.x.x.x ^ x.x.x.x: ESP(spi=0x78e02e92,seq=0xb7), length 100 10:12:13.210228 00:12:c1:ce:90:08 ^ Broadcast, ethertype IPv4 (0x0800), length 134: x.x.x.x ^ x.x.x.x: ESP(spi=0x78e02e92,seq=0xb8), length 100
Thank you for the answer. The IPs are both ends of a VPN tunnel. Source IP is the local gateway external IP and the destination is the peer gateway IP.
The IP packet is forwarded to the right interface, so to my understanding the layer 2 part is working. we see no ethertype ARP requests to know the IP.
Still, the packet is forwarded to the outgoing interface, but with a layer 2 broadcast MAC as destination.
Other VPNs are running fine via the same default gateway, the only difference is the peer IP, and for one specific IP, a layer 2 broadcast is send.
This is an example of something that works:
10:14:08.809013 00:12:c1:ce:90:08 ^ 00:00:5e:00:01:33, ethertype IPv4 (0x0800), length 134: 198.45.128.10 ^ 64.62.2.253: ESP(spi=0xce785fc9,seq=0x1f), length 100 (IPs changed)
The question is more, if there is any situation where the packet below is valid according to RFC. I have a ticket with Checkpoint but I wanted to ask here also.
10:12:10.207381 00:12:c1:ce:90:08 ^ Broadcast, ethertype IPv4 (0x0800), length 134: x.x.x.x ^ x.x.x.x: ESP(spi=0x78e02e92,seq=0xb7)
The MAC address in question suggests it's going to a VRRP cluster of some sort.
See: Virtual Router Redundancy Protocol - Wikipedia
What should be the actual next-hop in this case?
Yes.
when it Works, the package should be forwarded to 00:00:5e:00:01:33 which is the Internet routers VRRP MAC.
10:14:08.809013 00:12:c1:ce:90:08 ^ 00:00:5e:00:01:33, ethertype IPv4 (0x0800), length 134: 198.45.128.10 ^ x.x.x.x: ESP(spi=0xce785fc9,seq=0x1f), length 100
When it fails the VRRP MAC is replaced with a broadcast MAC.
10:12:10.207381 00:12:c1:ce:90:08 ^ Broadcast, ethertype IPv4 (0x0800), length 134: 198.45.128.10 ^ x.x.x.x: ESP(spi=0x78e02e92,seq=0xb7), length 100
It is important to mention that this only happened for one VPN!
Sounds like a TAC case is in order then.
Did you ever solved this? Seeing the same thing on a VSX platform running R80.20 Take_33.
Without knowing anything about your configuration or other errors you encountered, what traffic you were trying to initiate through, etc, it's difficult to say why.
Explaining what the different IPs are would be helpful (having them all x.x.x.x doesn't help).