Palo Alto interfaces Aggregate Ethernet mode Layer "2" - Log Monitor more details
Hello Live Community, 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 ).
-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 18.104.22.168.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 22.214.171.124 service/destination port 53
-2 Rules source 126.96.36.199.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? 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 ? Could this be happening through the use of Re-tagging-VLAN-Translation ? Does it look like this in the log traffic monitor?
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).
That is to say, should be applied example ACL source destination - destination source ?
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?
As always thanks for the support, good vibes and collaboration. Could you support me with the comments in the post, especially Vwire environments and / or Layer 2, where in the log monitor of a session, you see both the client to server flow, as the client to server (CS - SC flows)? This is normal in layer 2 and / or Vwire ? but this applies to the flow that you see in the log-traffic, log monitor-traffic or also at the level of policies ? should be applied so ? in both directions in Layer 2 environment and / or Vwire ? I do not think you should apply policies in both directions ACL stateles type ? or yes ? or are still stateful type policies ?
Thanks as always for your support, your advice, good vibes and collaboration.
I remain attentive
Hello @TomYoung , thank you for your comments.
With Vwire or with Layer 2 ? You don't see both flows in the traffic logs then? You only see one flow ? so is there an option that allows you to visualize these logs more in depth in the FW or is it because in this case for example ?
Layer 2 - Subinterfaces vlan tagged arrives on say the IN interface tagged 20,40,50,100,150 and when it goes out to the OUT interface of layer 2 it comes out as 21,41,51,101,151, i.e. in layer two the PA is doing a vlan retag, and at the vlan config level, both the subinterface in, example in.20 and out.21 are associated to the same VLAN in Palo Alto, that is to say a VLAN 20_21 that is associated to the interfaces in.20 and out.21 and so on with the rest, PA, in Network/VLANs section in the GUI. I know for this vlan retag that I see that in the traffic log ? ie client to server / server to client ? or is it by some option, I do not know if it is the same but I ever saw, that by default the PA summarizes the logs that are displayed in traffic log monitor, but there is a command to remove the summary and extend and practically display "everything" is that that is applied in these FWs ?
Because I tell you, I am very surprised to see those flows in the traffic log, not in the session log, but in the traffic-log-monito log:
-192.168.100.100 to 192.168.200.100 sport 45020 to dport 22
-192.168.200.100 to 192.168.100.100.100 sport 22 to dport 45020.
When it is normal in routing or in most that I have had to intervene is to see only: -192.168.100.100 to 192.168.200.100 sport 45020 to dport 22 and already ....
With Vwire with vwire you do not see what I said about the traffic log, but with "Layer 2" with the specific case of vlan retag ? or without it but with layer 2 you see something like that ?
So even if you see that in the traffic logs, it means that it is still applying stateful policies and not stateles ? even if it is layer 2 or vwire ?
I remain attentive, thanks for the collaboration
Hello colleagues, my apologies, I hope you don't mind that I am mentioning you in this post, but I really require your vision, your advices, your expertise, your collaboration and your vast and great experience in this. I thank you in advance for everything you can tell me related to the post and the replies to the post.
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).
Test PC -------VLAN1/Default----IN--1/1PA--Out1/2----VLAN1/Default------Local network ------- Router/Modem------Internet Access.
I check the log monitor traffic and... same issue, just configuring the base.
-From Zone: IN / To Zone Out / Source 192.168.1.18 / Destination 188.8.131.52 / To port 53 / Application dns / Allow / Rule Allow_In_to_Out
-From Zone IN to Zone OUT / Source 184.108.40.206 / Destination 192.168.1.18 / To port 65311 / Application dns / Allow / Rule Allow_In_to_Out
I have attached pictures so you can see for yourselves.
I would really appreciate it if everyone could help me find an explanation for this. I think it may be because as both Layer 2 interfaces are associated to the same VLAN (VLAN type defined in Palo Alto - Network VLANs) it is replicating. I am replicating what I saw on the client, only in my case with VLAN 1 or the default vlan. I say that implementation that I am reviewing was not made by me, there is not much information about why it was set up like this, but I must understand, because they do the vlan Retag in PROD when they go from IN they arrive as 10.20.30, etc. and when they go through to Out come out as 11,21,31, but both subinterfaces Tagged as 10 and 11, belong to the same Palo Alto VLANs ( Network - VLANs ), that is, the Layer 2 VLAN TAG 10 subinterface and subinterface 11 belong to the same PA VLANs (Palo Alto - Network VLANs)
Thank you very much for the good vibes, for your time, for the collaboration.
Hi @Metgatz ,
Yes, sir. I understood from the 1st post the issue you were seeing. It is strange. I have not seen it with my customers that run VWire, or with L2 interfaces on my own network.
Maybe it is the VLAN retag. The VLAN is not part of the 6-tuple key that makes up a session. So, a change should not cause a new session for return traffic. https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClVECA0
Thanks as always for the collaboration.
Yes, it could be the subject of VLAN ReTAG, but in the LAB that I set up, if you look at my last comment, where I give details of the LAB with Layer 2 interfaces, at no time am I using vlan TAG or vlan retag, all via vlan 1 , ie everything by default untagged. I also thought that the issue, the issue was there, but when doing the LAB, and seeing the same thing in the Log Traffic sessions, or is it a Normal behavior, is that at the Network-VLANs level, since the two interfaces are from home LAB causes that... The truth is that this topic is quite "interesting" but since it happens to everyone I need to understand the logical and concrete explanation, that's why I assumed it will be that all Layer 2 environments do share the Logs Monitor Traffic viewer ? Because the same thing happens in my lab, and as I reiterate, without ReTAG VLAN.
And I'm sorry if I go back and say the same thing again, it's that I like to give details of the information that I share and the more details the better, and also comment that for my part of course I review, I investigate, now I think about the LAB, to find out what happens with this, if this behavior of Layer is "Normal", see both flows in the log monitor or what ...
Thank you, as always, for your collaboration, support and comments.
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!