Packet flow question

[indevis]

Hi everybody,

Device: PA-500

Software: 3.1.7

we have a problem with our vpn tunnels. The tunnels are up and running,

but when I try to connect or ping a system over the tunnel we are getting timeouts.

To figure out what happens, I did a packet flow all and a packet capture and here I get

an entry which I can not explain.

"L2 broadcast cannot be forwarded in L3 mode"

I'm getting this entry after ther route lookup for the vpn peer gateway.

== Mar 22 09:08:47 ==
Packet received at forwarding stage
Packet info: len 1042 port 16 interface 16
  wqe index 229211 packet 0x0x8000000416ff00ce
Packet decoded dump:
L2:     00:24:73:79:43:81->00:1b:17:13:2e:10, type 0x0800
IP:     10.x.x.x->192.168.x.x, protocol 1
        version 4, ihl 5, tos 0x00, len 1028,
        id 61358, frag_off 0x0000, ttl 127, checksum 32071
ICMP:   type 8, code 0, checksum 64558, id 512, seq 21553
Forwarding lookup, ingress interface 16
L3 mode, virtual-router 2
Route lookup in virtual-router 2, IP 192.168.x.x
Route found, interface tunnel.21, zone 6
Packet enters tunnel encap stage, tunnel interface tunnel.21
Resolved tunnel 3
Forwarding lookup, ingress interface 23
L3 mode, virtual-router 2
Route lookup in virtual-router 2, IP x.x.x.x (external)
L2 broadcast cannot be forwarded in L3 mode

For example the next packet is working fine:

== Mar 22 09:08:52 ==
Packet received at forwarding stage
Packet info: len 1042 port 16 interface 16
  wqe index 229109 packet 0x0x8000000416fdf0ce
Packet decoded dump:
L2:     00:24:73:79:43:81->00:1b:17:13:2e:10, type 0x0800
IP:     10.x.x.x->192.168.x.x, protocol 1
        version 4, ihl 5, tos 0x00, len 1028,
        id 61429, frag_off 0x0000, ttl 127, checksum 32000
ICMP:   type 8, code 0, checksum 64302, id 512, seq 21809
Forwarding lookup, ingress interface 16
L3 mode, virtual-router 2
Route lookup in virtual-router 2, IP 192.168.x.x

Route found, interface tunnel.21, zone 6
Packet enters tunnel encap stage, tunnel interface tunnel.21
Resolved tunnel 3
Forwarding lookup, ingress interface 23
L3 mode, virtual-router 2
Route lookup in virtual-router 2, IP x.x.x.x

Route found, interface ethernet1/8, zone 4, nexthop y.y.y.y

Resolve ARP for IP y.y.y.y on interface ethernet1/8
ARP entry found on interface 23

After this, the packet is dropped, but sometimes its working and the route lookup works fine!

Has somebody a hint for me!

Regards

Christian

[gsamuels]

We suggest confirming the routing on the remote side of the vpn, however this does not explain why this is failing intermittently.

This may require further investigation, you may need to open a case with support.

[indevis]

Thanks for you answer.

But the problem is, that we had changed the hardware one week ago.

Because we had some issues in the logs, that the memory is corrupted.

We made a RMA, a now the new machine is running.

The config and the software release is the same as before.

And, what should I say, before we changed it it was working with no timeouts or connection lose.

The other side of the VPN were not changed in any way.

Now we have updated to 3.1.8 but with no success, this weired behavior is still happening.

I think there is no other chance to open a case.

[hmklette]

Hi,

I'm seeing the exact same thing on one of our PA-500s running 3.1.9

"L2 broadcast cannot be forwarded in L3 mode"

I cannot figure out why it is saying this, as the ICMP type 8 packet entering the firewall interface is routed through 2 routers before it hits the firewall, hence it cannot be a L2 packet.

Is there a hotfix or workaround for this issue?

Regards,

Hans

[indevis]

Hi Hans,

in our scenario this happens in conjunction with VPN Tunnels.

And it seems that in some scenarios with the releases 3.1.7+8+9

can be some problems.

For sure, this is not happening in all implementations.

But when it happens, you can make a downgrade to 3.1.6

to solve this problem.

In our scenario the downgrade to 3.1.6 works fine.

Regards

Christian

[hmklette]

Hi,

Thanks for the reply,

Yes it happens in VPN tunnels from one particular box and towards 5 other ones also running 3.1.9.

The other 5 PA500 boxes also have VPNs between them, but we see no packetloss on those VPNs.

So I guess the quickfix to this, is to downgrade to 3.1.6, as I don't want to go for 4.0.2.

Regards,

Hans

[mrajdev · Accepted solution]

This issue is resolved in 4.0.3 and affect release 3.1.7, 3.18 and 3.1.9.

Hope this helps.

Thanks