VPN Anyconnect UDP session.

[Sergio Valente]

My first time using this service ... please be gentle.

I recently setup a vpn anyconnect for a specific application.  My question,  if  I use the command   " show conn"

VPN01# sh conn | i 172.18.7.36

UDP Outside 172.18.7.36:1123 DMZ_ADM 10.7.16.57:81, idle 0:00:00, bytes 73324, flags -

UDP Outside 172.18.7.36:1123 DMZ_ADM 10.7.32.107:81, idle 0:00:00, bytes 73232, flags -

UDP Outside 172.18.7.36:1123 DMZ_ADM 10.7.32.41:81, idle 0:00:00, bytes 73232, flags -

UDP Outside 172.18.7.36:81 DMZ_ADM 10.7.32.41:3765, idle 0:00:02, bytes 5075905, flags -

UDP Outside 172.18.7.30:81 Outside 172.18.7.36:1123, idle 0:00:00, bytes 73186, flags -

UDP Outside 172.18.7.37:81 Outside 172.18.7.36:1123, idle 0:00:00, bytes 16744, flags -

VPN01#

In the above listing I know that device 172.18.7.30 is not connected ( for at least 3hours). Why is it that I see a UDP session between 172.18.7.30  and 172.18.7.36 ? 

Is my interpretation of a UDP session incorrect ?

Note that I am using version

Cisco Adaptive Security Appliance Software Version 8.3(1)
Device Manager Version 6.3(1)

anyconnect-win-2.4.1012-k9.pkg

Thanks for your help.

Sergio

[Jennifer Halim]

What port are you actually using for the AnyConnect VPN connection?

By default, it will use TCP/443, and unless you enable DTLS, then it will use UDP/443. Or if you have changed that connection to a different port number.

From the connection that you have highlighted, it seems that the connection is actually UDP/1123, and looks like the 2 ip addresses are actually in the same subnet, are you sure that is your VPN connection?

[Sergio Valente]

What port are you actually using for the AnyConnect VPN connection?

By default, it will use TCP/443, and unless you enable DTLS, then it will use UDP/443. Or if you have changed that connection to a different port number.

I was hopping to insert my image here,  but  on my ASDM my access port is 443 and my  DTLS port is 443 , both enabled on the outside interface.

From the connection that you have highlighted, it seems that the connection is actually UDP/1123, and looks like the 2 ip addresses are actually in the same subnet, are you sure that is your VPN connection?

Jennifer, as your last question..  I need to explain  the context of the application.

I have 5  mobile  trucks,  each with a  Anyconnect vpn connection to my ASA.    Each truck can talk to the server on my inside network or  talk between each other  ( 2 ips on the same subnet).  When the trucks exchange information between each other, they send UDP packets on destination port 81.

My question again .. how should I interpret the UDP session displayed using the command “ show conn” . If I know that 172.18.7.30 is not connected. Note that each truck has a config file that defines the IP address of the other trucks and that at each 5 seconds it sends out a UDP packet port81 on the  VPN TUNNEL.

UDP Outside 172.18.7.30:81 Outside 172.18.7.36:1123, idle 0:00:00, bytes 73186, flags -

Thanks again for your help.

Sergio  

[Jennifer Halim]

Thanks for the update and clarification.

Base on the output of "sh conn" provided:

UDP Outside 172.18.7.30:81 Outside 172.18.7.36:1123, idle 0:00:00, bytes 73186, flags -

The idle timeout is 0, that means that the communication is still happening between the 2 hosts. Are you seeing that the number of bytes increase if you perform the sho conn on that ip address a few times within a minute period?

For UDP traffic, the timeout is 2 minutes, ie: when it has been idled for 2 minutes, it will clear down the connection. Unless you have changed the timeout from 2 minutes, when it has been idled for 2 minutes, it will be cleared from the connection table.

[Sergio Valente]

Hi Jennifer,

Today I did some more testing:

I had a PC running an application that was trying to establish UDP sessions on port81.

The other PCs were all not connected.

Result:

When I do  show conn on my vpn ASA5520  is see  UDP sessions to the non connected PCs.  My interpretation of this must be that these are half-sessions.  The count moves, BUT this is probably due to the fact that the PC is retrying to establish the session.

There is nothing  in the packet that tells me that this is a half or a true session.  I was hoping that the flags would be different.. nope.  a true session or an attempt to establish a session seems to display the same flag options.

UDP Outside 172.18.7.30:81 Outside 172.18.7.36:1123, idle 0:00:00, bytes 73186, flags -

I  believe that the  flags are probably only used in TCP/IP sessions.

I don't think we can go much further with this case...  it seems that when it comes to UPD sessions there really no why of knowing if a session is true or trying to establish.

Regards,

Sergio

[Sergio Valente]

Hi Jennifer,

I want to thank you for help... What I seem to conclude is that when I use the  " show conn"  and the sessions that I am observing are UDP sessions, I need to use the options  " detail" to determine if I have a true UPD session or simply a  half session.

Example:

VPN01# sh conn | i 172.18.7.30

UDP Outside 172.18.7.30:1066 DMZ_ADM 10.7.16.57:81, idle 0:00:01, bytes 133507, flags -

UDP Outside 172.18.7.30:1066 DMZ_ADM 10.7.32.107:81, idle 0:00:01, bytes 133438, flags -

UDP Outside 172.18.7.30:1066 DMZ_ADM 10.7.32.41:81, idle 0:00:01, bytes 133392, flags -

UDP Outside 172.18.7.36:81 Outside 172.18.7.30:1066, idle 0:00:01, bytes 133392, flags -

ICMP Outside 172.18.7.30:0 DMZ_ADM 10.7.32.41:0, idle 0:00:01, bytes 539

ICMP Outside 172.18.7.30:0 DMZ_ADM 10.7.32.107:0, idle 0:00:01, bytes 539

UDP Outside 172.18.7.37:81 Outside 172.18.7.30:1066, idle 0:00:01, bytes 133392, flags -

UDP Outside 172.18.7.39:81 Outside 172.18.7.30:1066, idle 0:00:01, bytes 133392, flags -

VPN01#

Connections  from 172.18.7.30  to  ( .39, 37,36 and  10.7.16.57,  10.7.32.107, and 10.7.32.41) are not TRUE udp sessions.

PC39 , P37, P36 and PC 10.7.16.57 are not powered on.

PC 107, PC41  are powered on but not running the client application.

if  i use the cisco command   " sh conn detail address 172.18.7.39"  no connection is displayed

VPN01# sh conn detail address 172.18.7.39
86 in use, 229 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
VPN01#

However if i do  "sh conn detail address 172.18.7.30"  is see a TRUE connection

VPN01# sh conn detail address 172.18.7.30
87 in use, 229 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
UDP Outside:172.18.7.30/1066 DMZ_ADM:10.7.16.57/81,
    flags -, idle 0s, uptime 1h5m, timeout 2m0s, bytes 203374
UDP Outside:172.18.7.30/1066 DMZ_ADM:10.7.32.107/81,
    flags -, idle 0s, uptime 1h5m, timeout 2m0s, bytes 203305
UDP Outside:172.18.7.30/1066 DMZ_ADM:10.7.32.41/81,
    flags -, idle 0s, uptime 1h5m, timeout 2m0s, bytes 203236
UDP Outside:172.18.7.36/81 Outside:172.18.7.30/1066,
    flags -, idle 0s, uptime 1h5m, timeout 2m0s, bytes 203170
ICMP Outside:172.18.7.30/0 DMZ_ADM:10.7.32.41/0,
    idle 0s, uptime 1s, timeout 2s, bytes 661
ICMP Outside:172.18.7.30/0 DMZ_ADM:10.7.32.107/0,
    idle 0s, uptime 1s, timeout 2s, bytes 661
UDP Outside:172.18.7.37/81 Outside:172.18.7.30/1066,
    flags -, idle 0s, uptime 1h5m, timeout 2m0s, bytes 203236
UDP Outside:172.18.7.39/81 Outside:172.18.7.30/1066,
    flags -, idle 0s, uptime 1h5m, timeout 2m0s, bytes 203236
VPN01#

Again ... thanks for your help .. I think we can close this case.

[Jennifer Halim · Accepted solution]

Great observation and thanks for the update.

Please kindly mark the post as answered so others can learn from your post, and thank you for updating the most with the full description.

[Sergio Valente]

Hi Jennifer

Thanks again,

I posted as ANSWERED .. please confirm.

Sergio

[Jennifer Halim]

Great, thank you....