Packets dropped: invalid interface (route to second public network in trust interface)

[jocjak]

Hello All,

My system is multi vsys environment, I need to route traffic from untrust to trust.

My source is internet and destination is my second Public IP subnet in trust interface.

I investigate and found log from Global Counters "Packets dropped: invalid interface".

I try to add public ip to loopback and secondary ip but could not help. 

How can I solve this problem?

Thanks.

[santonic]

Why is second IP on trust interface?

Just put the second public IP on untrust interface (or to wherever ISP route directs it)  and PA will respond to ARP requests for it.

[jocjak]

My environment like this. I need to route traffic to my public IP via Palo.

[santonic]

I'm afraid i would need much more details to debug this (routing, interface configurations..)

But I suspect it's topology issue.

[jocjak]

Routing is correct. I can ping from Palo to public IP at HQ. (routing fib is correct)

When ping from internet packet drop by palo as follow counter log.

[reaper]

I have to agree with @santonic, we'll need much more information to dissect this issue 🙂

why is your public IP range on the trust interface?

for your multi vsys envirnment, did you create 2 vsys specific vritual routers or are you floating one VR outside the vsys (no vsys assigned to it)

The invalid interface error could be caused by your VR trying to forward the incoming packet to an interface that's outside the receiving vsys

flow_rcv_dot1q_tag_err usually means you are receiving 802.1q tagged packets on a non-tagged interface (or a tag that is not configured on one of the subinterfaces), you might want to look into that also

[pulukas]

Since you have multiple vsys and a path to the main office via both the internet and what looks like an internal link.  I think you are likely dealing with some asymmetrical routing.  Firewalls do not like asymmetrical routing and drop the packet.

To confirm this perform this test:

Run a trace route from the device at the trust interface to the public ip address at the home office in question.

Run a second trace route from the device on the public ip address at the home office back to your trust device (nat address if this is nat or the public address if it is public)

Compare the path on both and verify they go the same way.