To test this feature, visit your live site.

Edited: Feb 03, 2023

Palo Alto interfaces in Layer 2 - Portchannel- Tagged subinterfaces - Log Monitor more details

Palo Alto interfaces Aggregate Ethernet mode Layer "2" - Log Monitor more details

Hello, good afternoon, I have a huge question regarding what I see in the log monitor of some firewalls with Layer 2 Portchannels with sub-interfaces tagged vlan layer 2.

I have some customer firewalls, which have Layer 2 Interfaces with Portchannel Aggregate Ethernet, with Tagged subinterfaces ( 10 Vlans sub interfaces Layer 2 ).

When analyzing and t-shooting some sessions and traffic, I noticed something that I had not seen in the firewall with its interfaces, let's say in routing mode. I had not had the opportunity to deepen and/or review in depth issues with equipment in Interfaces portchannel Layer 2 sub interfaces tagged vlans.

What I noticed differently:

Normally on a computer with routed traffic you see this log( 1 ).

a-Source zone: Trust - Source IP 10.10.10.100 Destination zone Untrust, Destination IP 172.16.1.150 source port 45999 destination port sip 5060 app SIP. This in normal environments in a simple log

-But in Layer 2 mode you see this same connection two logs:

a-Source zone: Trust - Source IP 10.10.10.100 Destination zone Untrust, Destination IP 172.16.1.150 source port 45999 destination port sip 5060 app SIP

b-Source zone: Untrust - Source IP 172.16.1.150 Destination zone Trustt, Destination IP 10.10.10.100 source port 5060 destination port sip 45999 app SIP.

Now my doubt is that, then in Layer 2, you must make origin destination policies. Example if you want a flow source 10.10.10.10.100 destination 8.8.8.8.8 port/53 udp. I must make the old ACL type return security rule without stateful i.e. 2 rules with both flows: -1 Rules source 10.10.10.100 destination 8.8.8.8 service/destination port 53 -2 Rules source 8.8.8.8.8 destination 10.10.10.100 service/destination ( port 43667 ( random port of communication socket ).

In other words, in the log monitor, of a session, I see the log of the client to server, server to client flow. Excuse my ignorance or ignorance, but does the layer 2 firewall act like a stateless firewall?

That is to say, should be applied example ACL source destination - destination source ?Or is it just the log monitor view ? the policies are still stateful right ? it's just the log monitor-traffic view isn't it ?

I ask about an issue that occurred with SIP a bug SIP Tcp version 9.1.15.

A new application was generated to override sip, and apply the custom app.

Well now what was the topic was next: In the log monitor traffic, that's where this issue jumps. In the log monitor, view those flows.

And everything that appeared as source 5061 port and destination 49655 (random port of the socket that is displayed like this in the log monitor in this environment source port 5061 destination port 49655) was still marked as sip and not as the override app (hence the app custom and app overide are only based on destination port ). Just in version 9.1.14 there is a bug with SIP with TCP, the workaround remove the alg, it didn't work next workaround remove the inspection so we apply particular app and policy override. Therefore, when making a new override app with high ports, the typical random ones, we use 40000 to 65500. Well now with the two override apps, one for sip 5060 and 5061 OK. And with the override app for high ports 40,000 to 65,000, that traffic was no longer identified in the monitor as SIP, but as the new app, and thus the problem with SIP was solved, a problem that was fixed with version 9.1. 15 (we couldn't apply an upgrade at that very moment but we could apply a workaround). https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-release-notes/pan-os-9-1-addressed-issues/pan-os-9-1-15-addressed-issues#:~:text=Fixed%20an%20issue%20where%20Session%20Initiation%20Protocol%20(SIP)%20REGISTER%20packets%20did%20not%20get%20transmitted%20when%20application%2Dlevel%20gateway%20(ALG)%20and%20SIP%20Proxy%20were%20enabled%2C%20which%20caused%20a%20SIP%2Dregistration%20issue%20in%20environments%20where%20TCP%20retransmission%20occurred.

Has anyone had real experience, not theoretical and practical, of productive firewalls in layer 2? Is there a point where this condition is highlighted and details of it are given?

Stay tuned

Thanks

Best regards

9 comments

Comments (9)

Reaper

Feb 04, 2023

Hmm

In your log viewer enable the ingress/egress interfaces to see if you're not flipping interfaces somehow, could it be your switch is bridged somehow?

Reaper

Feb 10, 2023

Replying to

Hi! I've double-checked my own L2 deployments and I am unable to reproduce what you are seeing, which leads me to believe your network is probably designed differently from mine.

Reaper

Feb 10, 2023

Replying to

Mine are mostly l2 interfaces connected to an individual device (acting like an access swithch) or each interface to a different switch so there is no possibility for loops

MetgatzGR

Feb 10, 2023

Replying to

Hi @Reaper, thanks for your comment and collaboration.

In this case they are like this in Production:

Switch-Distribución-01=====Portchannel=====VLAN-TAG AE1.subinterfaces=100,200,300,400==FW-Palo-Alto-PA-52XX-RETAG-VLAN-VLAN-traslation===VLAN-TAG-AE2.subinterfaces-101,201,301,401====Portchannel====Swtich-Distrubición-02.

Thank you for your valuable time

Regards

MetgatzGR

Feb 03, 2023

Hello @Reaper as always thanks for the support, have you seen the comments, mostly Vwire and/or Layer 2 environments, where in the log monitor, of a session, you see both the client to server flow and the client to server flow ? very different from routing, where you only see 1 ? This is normal ? but this applies to the traffic flow or also to the policies ? I do not think that you should apply policies in both directions ACL stateles type ? or yes ? or is it still stateful type policies ?

Thanks as always for your support, your advice, good vibes and collaboration.

Regards

Reaper

Feb 04, 2023

Replying to

Hey! This is actually not normal, vwire works exactly like other modes in regards to state

Is traffic flowing through both vwires and are you reusing zones (if yes, are the vwires serial or parallel to eachother)

MetgatzGR

Feb 04, 2023

Replying to

Hello @Reaper thanks as always for your comments and your time.

This is how it is configured, or at least a very referential example very near to the PROD environment with "Interfaces Layer 2/Zone Layer 2 AE VLAN Tagged and Retagged IN/OUT subinterfaces":

The connection to the PA arrives at LACP AE "layer 2" IN, and TAG subinterfaces 100,200,300,400, each subinterface in its respective Layer 2 zone ( example Zone Layer 2 In_100 Ae1.100, In_200 Ae1.200...etc ) . Then it goes to LACP AE layer 2 OUT, and its TAG o re-tagging subinterfaces 101,201,301,401, ( same Zone Layer 2 Out_101 AE2.101, Out_201 Ae2.201 etc. ), each subinterface with its respective Layer 2 zone and VLAN TAG.

Switch=====AE====VLANs 100,200,300,400===IN-Subinterfaces IN100,IN200,IN300,IN400==PAFW==OUT==Subnterfaces====OUT101,OUT200,OUT300,OUT400====AE===Switch

It is configured in the GUI section of the "Networks - VLANs": VLANs

: called: "100_101" (with subinterface In.100 and Out.101) another called "200_201"(with subinterface In.200 and Out.201), other called "300_301" ( with subinterfaces In.301_Out.302 ), etc, etc...

Now what are the pros and cons of these implementations? what are the use cases? When is it necessary to execute something like this Re-tagging of vlan ? Can it be done only in Layer 2 and/or Vwire? When does the need to have something like this arise? Is this because of the retagging? or because of the "Network - VLANs" configuration?

-I have done a LAB to replicate the behavior.

With a PA with a Layer 2 IN interface and another Layer 2 OUT interface.

IN zone Ethernet interface 1/1 - Layer 2 - VLANs: VLAN_1 OUT zone Ethernet interface 1/2 - Layer 2 - VLANs: VLAN_1

VLAN type defined in Palo Alto - "Network - VLANs" - VLAN Config named: "VLAN_1" which includes the Ethernet 1/1 and Ethernet 1/2 interfaces.

Wide test security policy ( both match)

Allow _IN_to_Out: Zone In to Out. (Hit a lot) Allow_Out_to_IN_Zone Out to IN. (Hit a lot).

Testing environment:

Test PC -------VLAN1/Default----IN--1/1PA-FW--Out1/2----VLAN1/Default------Local network ------- Router/Modem------Internet Access.

I check the log monitor traffic and... same issue, just configuring the base.

logmonitor: -From Zone: IN / To Zone Out / Source 192.168.1.18 / Destination 8.8.8.8 / To port 53 / Application dns / Allow / Rule Allow_In_to_Out

-From Zone IN to Zone OUT / Source 8.8.8.8 / Destination 192.168.1.18 / To port 65311 / Application dns / Allow / Rule Allow_In_to_Out

Thank you for your time and kind cooperation

Cheers

Forum: Forum