I have a question related to how PIX/ASA firewalls maintain UDP session information. My understanding is that when there is a UDP connection from a lower to a higher security zone, the UDP server (e.g. DNS) in the higher security zone responds to the UDP query even if the outbound UDP is blocked (i.e. even if there is excplicit ACL blocking DNS traffic from inside to outside).
So, how would the FW track the different UDP sessions while UDP is connectionless protocol. I can understand it with TCP as TCP sessions have unique session numbers, but how is that dealt with UDP protocols?
Your first statement is not true, since if the pix allowed the inbound packet from the outside to the inside, then it would also build a connection in its connection table. If the reply packet matched this connection it would be allowed through the firewall, regardless if there was an inbound acl applied on the inside interface, or an outbound acl applied to the outside interface.
The firewall tracks UDP sessions by the 4 touple of the UDP connection: SRC IP and port DST ip and port. It does the exact same thing with UDP. Any firewall works this way.
What you said doesn't conflict with my original statement that the FW doesn't require an explicit ACL to permit UDP or TCP responses as you can read in my first paragraph.
Ok, so it makes sense that the FW keeps track of UDP sessions using the SRC/DST ip and port numbers. On the other hand, with TCP connections won't the FW also keep records of session number besides the SRC/DST ip and port?
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...