Help understanding allowed Teamviewer UDP connection

[patoberli]

Hello all

I'm running an ASA in transparent mode with several contexts.

For simplicity lets assume I have two context, one for the 192.168.0.0/24 and one for the 192.168.1.0/24.

The firewall rules are in the IN direction on the OUTSIDE interface. Outgoing traffic is allowed with protocol IP.

The last rule in both rule sets is:

access-list OUTSIDE extended deny ip any any log

There is no permitted firewall rule that allows incoming UDP traffic on Port >50000 to any IP in the subnet, which my CSM also confirms with a query.

Client 1 is 192.168.0.10 and client 2 is 192.168.1.20.

We tested teamviewer today, client1 was the admin-host and client2 was the destination-host.

A wireshark showed now, as did the firewall log, that both clients opened a UDP connection to each other with the same IP/Port combination, just vice versa. So far I still understand what's going on.

What did buffle me now though, client1 was able to directly communicate with client2, although neither firewall ruleset allows an incoming UDP connection! They (ab)used the seemingly two other connections, of which each client opened one, to communicate that way.

I thought that should be blocked? I think I'm lacking some basic UDP firewall function knowledge, could anybody please enlighten my why those two clients were able to directly communicate with each other?

Thanks
Patrick

[Marius Gunnerud]

It is difficult to say without more knowledge of your network.  Could you post a network diagram of your setup and please post your ASA's full configuration (remove public IPs and usernames / passwords).

--

Please select a correct answer and rate helpful posts

[patoberli]

The very much simplified configuration of those two transparent context interfaces looks like this:
Context1:

interface BVI1
 ip address 192.168.0.4 255.255.255.0 standby 192.168.0.5
interface Port-channel1.1145
 nameif outside
 bridge-group 1
 security-level 0
interface Port-channel1.145
 nameif inside
 bridge-group 1
 security-level 100
access-list INSIDE extended permit ip any any
access-list OUTSIDE extended deny ip any any log
access-group INSIDE in interface inside
access-group OUTSIDE in interface outside
route outside 0.0.0.0 0.0.0.0 192.168.0.1 1
timeout xlate 3:00:00
timeout pat-xlate 0:00:30
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout tcp-proxy-reassembly 0:01:00
timeout floating-conn 0:00:00
aaa proxy-limit disable
no snmp-server contact
no snmp-server location
telnet timeout 5
mac-address-table aging-time 5
sysopt connection tcpmss 9096
ssh key-exchange group dh-group1-sha1
no threat-detection statistics tcp-intercept
class-map axapta_timeout
 match access-list axapta_timeout
class-map inspection_default
 match default-inspection-traffic
class-map timeout_sistore_videoueberwachung
 match access-list timeout_sistore_videoueberwachung
policy-map CSM_PM_global_1
 class inspection_default
  inspect ftp
  inspect icmp
  inspect h323 h225
  inspect h323 ras
  inspect rsh
  inspect sqlnet
  inspect skinny
  inspect sunrpc
  inspect xdmcp
  inspect sip
  inspect netbios
  inspect tftp
 class timeout_sistore_videoueberwachung
  set connection random-sequence-number disable
  set connection timeout idle 0:00:00
 class axapta_timeout
  set connection timeout idle 12:00:00
 class class-default
  set connection random-sequence-number disable
mac-address-table static outside 0008.e3ff.fd90

Context 2:

interface BVI1
 ip address 192.168.1.4 255.255.255.0 standby 192.168.1.5
interface Port-channel1.1140
 nameif outside
 bridge-group 1
 security-level 0
interface Port-channel1.140
 nameif inside
 bridge-group 1
 security-level 100
access-list INSIDE extended permit ip any any
access-list OUTSIDE extended deny ip any any log
access-group INSIDE in interface inside
access-group OUTSIDE in interface outside
route outside 0.0.0.0 0.0.0.0 192.168.1.1 1
timeout xlate 3:00:00
timeout pat-xlate 0:00:30
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout tcp-proxy-reassembly 0:01:00
timeout floating-conn 0:00:00
aaa proxy-limit disable
no snmp-server contact
no snmp-server location
telnet timeout 5
mac-address-table aging-time 5
sysopt connection tcpmss 9096
ssh key-exchange group dh-group1-sha1
no threat-detection statistics tcp-intercept
class-map axapta_timeout
 match access-list axapta_timeout
class-map inspection_default
 match default-inspection-traffic
class-map timeout_sistore_videoueberwachung
 match access-list timeout_sistore_videoueberwachung
policy-map CSM_PM_global_1
 class inspection_default
  inspect ftp
  inspect icmp
  inspect h323 h225
  inspect h323 ras
  inspect rsh
  inspect sqlnet
  inspect skinny
  inspect sunrpc
  inspect xdmcp
  inspect sip
  inspect netbios
  inspect tftp
 class timeout_sistore_videoueberwachung
  set connection random-sequence-number disable
  set connection timeout idle 0:00:00
 class axapta_timeout
  set connection timeout idle 12:00:00
 class class-default
  set connection random-sequence-number disable
mac-address-table static outside 0008.e3ff.fd90

With this configuration (removed other firewall rules, which do not match the intended traffic) Teamviewer seems to be able to create a direct connection over UDP between two hosts, each connected to one context.

[patoberli]

I just had a thought, I removed a multicast allowing rule in the above rule set, Wireshark didn't show anything about Multicast and it was the correct source and destination IP in the captured traffic, but maybe I need to recheck that.

Multicast allowing rule(s):

object-group network router-140
 network-object 192.168.1.1 255.255.255.255
access-list OUTSIDE extended permit igmp object-group router-140 224.0.0.0 255.0.0.0
access-list OUTSIDE extended permit udp object-group router-140 224.0.0.0 255.0.0.0 eq 1985
access-list OUTSIDE extended permit pim object-group router-140 224.0.0.0 255.0.0.0
access-list OUTSIDE extended permit igmp object-group router-140 host 239.2.0.2
access-list OUTSIDE extended permit udp object-group router-140 host 239.2.0.2 eq 1985
access-list OUTSIDE extended permit pim object-group router-140 host 239.2.0.2

[Marius Gunnerud]

I don't think multicast has anything to do with your issue as TeamViewer runs over TCP 80 and 443.  But it doesn't hurt to put it back and test.

With this configuration (removed other firewall rules, which do not match the intended traffic) Teamviewer seems to be able to create a direct connection over UDP between two hosts, each connected to one context.

Are you saying that with the configuration you posted, teamviewer works?

--

Please select a correct answer and rate helpful posts

[patoberli]

I did not test with this exact configuration (as there are a few specific TCP rules and one or two UDP rules, which are restricted to a source or destination IP and ports <5000), but yeah it worked.

And here the log file of the two context (sorted by time, have a look at the same connection number, over the two context)

"Receive Time",Severity,"Event Type ID","Event Name",Device,Source,"Source Service",Destination,"Destination Service",Action,Description
"2/25/16 2:28:29 PM",Informational,106100,"Permit/Denied by ACL",145-verw-client,192.168.1.27,udp/62486,192.168.0.232,udp/52436,denied,"access-list OUTSIDE denied udp outside/192.168.1.27(62486) -> inside/192.168.0.232(52436) hit-cnt 1 300-second interval [0xb74026ad, 0x0]"
"2/25/16 2:27:30 PM",Informational,302016,"Teardown UDP",140-id,192.168.0.232,udp/52436,192.168.1.27,udp/62486,teardown,"Teardown udp connection 905011109 for outside:192.168.0.232/52436 to inside:192.168.1.27/62486 duration 0:04:02 bytes 3951330"
"2/25/16 2:27:30 PM",Informational,302016,"Teardown UDP",145-verw-client,192.168.1.27,udp/62486,192.168.0.232,udp/52436,teardown,"Teardown udp connection 905011119 for outside:192.168.1.27/62486 to inside:192.168.0.232/52436 duration 0:04:02 bytes 3951138"
"2/25/16 2:23:28 PM",Informational,302015,"Built UDP",145-verw-client,192.168.0.232,udp/52436,192.168.1.27,udp/62486,built,"Built outbound udp connection 905011119 for outside:192.168.1.27/62486 (192.168.1.27/62486) to inside:192.168.0.232/52436 (192.168.0.232/52436)"
"2/25/16 2:23:28 PM",Informational,302015,"Built UDP",140-id,192.168.1.27,udp/62486,192.168.0.232,udp/52436,built,"Built outbound udp connection 905011109 for outside:192.168.0.232/52436 (192.168.0.232/52436) to inside:192.168.1.27/62486 (192.168.1.27/62486)"
"2/25/16 2:23:28 PM",Informational,106100,"Permit/Denied by ACL",145-verw-client,192.168.1.27,udp/62486,192.168.0.232,udp/52436,denied,"access-list OUTSIDE denied udp outside/192.168.1.27(62486) -> inside/192.168.0.232(52436) hit-cnt 1 first hit [0xb74026ad, 0x0]"
"2/25/16 2:16:21 PM",Informational,106100,"Permit/Denied by ACL",145-verw-client,192.168.1.27,udp/63200,192.168.0.232,udp/52620,denied,"access-list OUTSIDE denied udp outside/192.168.1.27(63200) -> inside/192.168.0.232(52620) hit-cnt 1 300-second interval [0xb74026ad, 0x0]"
"2/25/16 2:13:33 PM",Informational,302016,"Teardown UDP",140-id,192.168.0.232,udp/52620,192.168.1.27,udp/63200,teardown,"Teardown udp connection 904566675 for outside:192.168.0.232/52620 to inside:192.168.1.27/63200 duration 0:02:12 bytes 169875"
"2/25/16 2:13:33 PM",Informational,302016,"Teardown UDP",145-verw-client,192.168.1.27,udp/63200,192.168.0.232,udp/52620,teardown,"Teardown udp connection 904566683 for outside:192.168.1.27/63200 to inside:192.168.0.232/52620 duration 0:02:12 bytes 169683"
"2/25/16 2:11:20 PM",Informational,302015,"Built UDP",145-verw-client,192.168.0.232,udp/52620,192.168.1.27,udp/63200,built,"Built outbound udp connection 904566683 for outside:192.168.1.27/63200 (192.168.1.27/63200) to inside:192.168.0.232/52620 (192.168.0.232/52620)"
"2/25/16 2:11:20 PM",Informational,302015,"Built UDP",140-id,192.168.1.27,udp/63200,192.168.0.232,udp/52620,built,"Built outbound udp connection 904566675 for outside:192.168.0.232/52620 (192.168.0.232/52620) to inside:192.168.1.27/63200 (192.168.1.27/63200)"
"2/25/16 2:11:20 PM",Informational,106100,"Permit/Denied by ACL",145-verw-client,192.168.1.27,udp/63200,192.168.0.232,udp/52620,denied,"access-list OUTSIDE denied udp outside/192.168.1.27(63200) -> inside/192.168.0.232(52620) hit-cnt 1 first hit [0xb74026ad, 0x0]"

[Marius Gunnerud]

If your configuration works, what do you need help with?

--

Please remember to select a correct answer and rate helpful posts

[patoberli]

I wonder why Teamviewer was able to create this connection. Based on my knowledge it should have been blocked and not permitted and I wonder now if I have a big lack of understanding how the ASA handles UDP traffic, or whatever the reason was that this connection was not blocked.

[Marius Gunnerud]

You are correct.  Context 2 should have dropped the packet on the outside interface.  But perhaps there is a routing or switching problem somewhere between client 1 and client 2.  Have you double checked the topology to make sure that the traffic has no other rout to client 2 other than going through the outside interface of context 2?

--

Please remember to select a correct answer and rate helpful posts

[patoberli]

Yes I have, only thing I haven't checked (didn't check mac-addresses in wireshark) is Multicast.

It looks as if both computer opened from their side of the firewall the same UDP connection and then the firewall allowed traffic directly over that connection. It even received (in my second try) the same connection ID on both context?!?

Also you can clearly see that both context logged the connection, so the traffic went through both firewalls.

[Marius Gunnerud]

is this a virtualized setup or is this on physical hardware?

If it is virtualized, this could be an VM issue.

--

Please remember to select a correct answer and rate helpful posts

[patoberli]

It's a physical ASA 5585-X.

I actually think it might be because both clients open at the same time a same looking outgoing UDP connection (from their respective view) and the ASA decides to use that, from the other client opened, connection. Not sure how the ASA checks it's connection/xlate/orwhatever table for already existing connections.

Could that be and should that be possible?