- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
03-22-2011 01:49 AM
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
06-29-2011 12:00 PM
This issue is resolved in 4.0.3 and affect release 3.1.7, 3.18 and 3.1.9.
Hope this helps.
Thanks
03-22-2011 06:38 PM
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.
03-23-2011 02:06 AM
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.
06-28-2011 06:32 AM
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
06-29-2011 03:42 AM
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
06-29-2011 03:51 AM
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
06-29-2011 12:00 PM
This issue is resolved in 4.0.3 and affect release 3.1.7, 3.18 and 3.1.9.
Hope this helps.
Thanks
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!