Enhanced Security Measures in Place:   To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.

Packet flow question

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

Packet flow question

L2 Linker

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

1 accepted solution

Accepted Solutions

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

Hope this helps.

Thanks

View solution in original post

6 REPLIES 6

L3 Networker

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.

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.

Not applicable

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

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

Not applicable

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

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

Hope this helps.

Thanks

  • 1 accepted solution
  • 4708 Views
  • 6 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!