10-26-2013 09:44 AM - edited 03-11-2019 07:56 PM
Hi all
Can anyone tell me how a firewall tracks the state of a udp connection?
Cheers
Solved! Go to Solution.
10-26-2013 12:49 PM
Hi,
I am not personally sure what else could be said about tracking UDP connections in general.
UDP compared to TCP doesnt contain much in its header for the ASA to keep track of.
You can check them here for example
http://nmap.org/book/tcpip-ref.html
TCP Header (click to enlarge)
UDP Header (click to enlarge)
If you want a Cisco sourced answer then this is what the CCNP certification material says about the subject
For UDP flows, the ASA tracks source and destination IP addresses and ports and the idle time since the last packet of the flow was seen by the ASA. For certain applications (such as DNS), the ASA also tracks request identifiers, to help it defend against packet-spoofing attacks. A UDP flow is created in the connection table if the ASA security policy permits it. Because UDP flows have no state machine, UDP flows are deleted only when they are idle for longer than the configurable UDP idle timer
So pretty much what I said in the above post.
Hope this helps
- Jouni
10-26-2013 09:59 AM
Hi,
Well the UDP connections don't really have a state to track like TCP.
I guess one of the most common things to track with regards UDP on the ASA firewall might be DNS inspection and things related to DNS queries. For example the ASA would allow only one reply to a DNS query with the "dns-guard" global configuration or the one "dns-guard" configuration in the "policy-map" configurations under the "inspect dns"
Otherwise I would imagine the first thing for the ASA to check is whether its rules allow the UDP Connection in question based on its destination/source address/port.
When the connections is allowed to form through the firewall then naturally all traffic related to that connection on the ASA is allowed.
If the connection (by default) is idle for more than 2 minutes the connection will be removed from the firewall because of the "timeout" configurations. Naturally with additional "policy-map" / "class-map" configurations you can change this timeout value for a specific UDP connection you want to something longer or you can even change it globally for all UDP traffic with changing the "timeout" configuration.
I imagine there is more things related to how ASA handles different UDP connections but the above are the things that come to mind at the moment.
Hope this helps
Please do remember to mark a reply as the correct answer if it answered your question.
- Jouni
10-26-2013 12:14 PM
Hi there
Thanks for the reply, however I feel as I need to know more about how they track udp connections
10-26-2013 12:49 PM
Hi,
I am not personally sure what else could be said about tracking UDP connections in general.
UDP compared to TCP doesnt contain much in its header for the ASA to keep track of.
You can check them here for example
http://nmap.org/book/tcpip-ref.html
TCP Header (click to enlarge)
UDP Header (click to enlarge)
If you want a Cisco sourced answer then this is what the CCNP certification material says about the subject
For UDP flows, the ASA tracks source and destination IP addresses and ports and the idle time since the last packet of the flow was seen by the ASA. For certain applications (such as DNS), the ASA also tracks request identifiers, to help it defend against packet-spoofing attacks. A UDP flow is created in the connection table if the ASA security policy permits it. Because UDP flows have no state machine, UDP flows are deleted only when they are idle for longer than the configurable UDP idle timer
So pretty much what I said in the above post.
Hope this helps
- Jouni
10-26-2013 08:41 PM
hi carl,
the ASA has a connection table (aka session table) that is used to track all connections permitted across the device.
this table maintains information not only connection-oriented/Transmission Control Protocol (TCP) sessions, but also the active communications, whether TCP or User Datagram Protocol (UDP), or based on advanced protocol inspection capabilities.
you could verify using the command show conn or show conn detail.
ciscoasa# show c?
call-home capture checkheaps checksum
chunkstat class clock compression
configuration conn console-output controller
coredump counters cpu crashinfo
crypto csc ctiqbe ctl-file
ctl-provider curpriv
ciscoasa# show conn
39 in use, 1008 most used
ESP outside VPN_Sydney_COLO inside VPN_Brisbane, idle 0:00:00, bytes 5928
UDP outside VPN_Melbourne:500 inside VPN_Brisbane:500, idle 0:01:13, bytes 168, flags -
ESP outside VPN_Sydney_COLO inside VPN_Brisbane, idle 0:00:09, bytes 127300
ESP outside VPN_HK_COLO inside VPN_Brisbane, idle 0:00:19, bytes 4732
UDP outside VPN_SanFrancisco:500 inside VPN_Brisbane:500, idle 0:01:12, bytes 716, flags -
UDP outside VPN_Hongkong:500 inside VPN_Brisbane:500, idle 0:01:19, bytes 504, flags -
UDP outside VPN_Sydney:500 inside VPN_Brisbane:500, idle 0:01:13, bytes 2296, flags -
GRE outside 203.x.x.1:0 inside VPN_Brisbane:0, idle 0:00:00, bytes 6495654, flags E
UDP outside VPN_Adelaide:500 inside VPN_Brisbane:500, idle 0:00:54, bytes 336, flags -
ESP outside VPN_Sydney_COLO inside VPN_Brisbane, idle 0:00:00, bytes 21292
ESP outside VPN_Sydney_COLO inside VPN_Brisbane, idle 0:00:09, bytes 289868
UDP outside VPN_Sydney_COLO:500 inside VPN_Brisbane:500, idle 0:00:09, bytes 51598992, flags -
ESP outside VPN_HK_COLO inside VPN_Brisbane, idle 0:00:06, bytes 4136
UDP outside VPN_HK_COLO:500 inside VPN_Brisbane:500, idle 0:00:19, bytes 1188, flags -
TCP outside 199.x.x.x:80 inside 10.1.50.136:56805, idle 0:00:58, bytes 0, flags UFR
TCP outside 199.x.x.x:80 inside 10.1.50.136:56804, idle 0:00:57, bytes 1321, flags UFRIO
TCP outside 199.x.x.x:80 inside 10.1.50.136:56775, idle 0:02:11, bytes 1254, flags UFRIO
TCP outside 199.x.x.x:80 inside 10.1.50.136:56774, idle 0:02:11, bytes 0, flags UFR
UDP outside VPN_NY_Site2:500 inside VPN_Brisbane:500, idle 0:01:18, bytes 336, flags -
TCP outside DIA_GW:179 inside VPN_Brisbane:33496, idle 0:00:00, bytes 41990954, flags UIO
UDP outside VPN_Perth:500 inside VPN_Brisbane:500, idle 0:00:33, bytes 4704, flags -
UDP outside VPN_Canberra:500 inside VPN_Brisbane:500, idle 0:01:12, bytes 168, flags -
GRE outside 203.x.x.1:0 inside VPN_Brisbane:0, idle 0:00:00, bytes 500076100, flags E
TCP outside 199.x.x.x:80 inside 10.1.50.136:56807, idle 0:01:26, bytes 0, flags U
ciscoasa# show conn detail
42 in use, 1008 most used
Flags: A - awaiting inside ACK to SYN, a - awaiting outside ACK to SYN,
B - initial SYN from outside, b - TCP state-bypass or nailed, C - CTIQBE media,
D - DNS, d - dump, E - outside back connection, F - outside FIN, f - inside FIN,
G - group, g - MGCP, H - H.323, h - H.225.0, I - inbound data,
i - incomplete, J - GTP, j - GTP data, K - GTP t3-response
k - Skinny media, M - SMTP data, m - SIP media, n - GUP
O - outbound data, P - inside back connection, p - Phone-proxy TFTP connection,
q - SQL*Net data, R - outside acknowledged FIN,
R - UDP SUNRPC, r - inside acknowledged FIN, S - awaiting inside SYN,
s - awaiting outside SYN, T - SIP, t - SIP transient, U - up,
V - VPN orphan, W - WAAS,
X - inspected by service module
ESP outside:VPN_London/41537 inside:VPN_Brisbane/2409,
idle 4s, uptime 4s, timeout 30s, bytes 76
ESP outside:VPN_Sydney_COLO/54414 inside:VPN_Brisbane/8341,
idle 0s, uptime 26s, timeout 30s, bytes 71524
UDP outside:VPN_Melbourne/500 inside:VPN_Brisbane/500,
flags -, idle 1m31s, uptime 1m31s, timeout 2m0s, bytes 168
ESP outside:VPN_Sydney_COLO/9125 inside:VPN_Brisbane/17362,
idle 27s, uptime 1m43s, timeout 30s, bytes 127300
ESP outside:VPN_HK_COLO/24294 inside:VPN_Brisbane/27579,
idle 12s, uptime 3m29s, timeout 30s, bytes 4936
UDP outside:VPN_SanFrancisco/500 inside:VPN_Brisbane/500,
flags -, idle 1m29s, uptime 4m13s, timeout 2m0s, bytes 716
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide