Teardown TCP connections with kaseya server (ASA 5510)

Answered Question
Sep 12th, 2011

Hi,

I have a problem with our kaseya agents.

normaly the agents has a persistent connection with the kaseya server (monitoring server),

The connection  re-established afther the next check-in of the agent, instead of a persistent connection. Now we need to wait to the next check-in before we can connect to the agent. This is a big performance issue, the check-in time of the agents are 3 minutes.

I see a lot of the following messages in de syslog:

6Sep 12 201120:27:48302013customer site52798
5721Built inbound TCP connection 5418112 for outside:(customer site)/52798 (customer site/52798) to inside:kaseya server/5721 (outsideIP/5721)

6Sep 12 201120:29:09302014customer site52798
5721Teardown TCP connection 5418112 for outside:(customer site)/52798 to inside:kaseya server/5721 duration 0:01:21 bytes 45 TCP FINs

I create a normal static nat rule from the kaseya server to a public ip address, and i define the protocols in de secutiry policy.

ICMP has been allowed.

cisco asa details:

System image file is "disk0:/asa824-k8.bin"

This platform has an ASA 5510 Security Plus license.

It's look like a connection time-out between the agents and our cisco asa.

I hope sombody can help me with this issue.

Kind Regards,

Felix

I have this problem too.
0 votes
Correct Answer by Poonguzhali Sankar about 2 years 7 months ago

That is exactly the problem.  Now, you added the config alright.  Is this applied via a service-policy?

Issue a "clear local x.x.x.x" for the IP address in question and try the connection again.

-KS

  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 5 (1 ratings)
mayrojas Mon, 09/12/2011 - 20:52

Hi Felix,

The key on this log is to check what the reason for the teardown is, as you can see the reason is for

TCP FINs, which means that both server and client agree to terminate the connection.

Do they used some kind of tcp option keep alive or something to maintain the connection up?

Mike

felixduivenvoorden Tue, 09/13/2011 - 01:02

this will be normal:

first a TCP/5721 connection and then a UDP connection to establish the "tunnel"

6          Sep 13 2011          09:54:48          302015          (customer site)          (kaseya server public)           Built inbound UDP connection 146684128493708668 for outside:(customer site)/5742 ((customer site)/5742) to inside:(kaseya server public)/5721 ((kaseya server private)/5721)

6          Sep 13 2011          09:54:48          302015          (customer site)          (kaseya server public)           Built inbound UDP connection 146684128493708667 for outside:(customer site)/5741 ((customer site)/5741) to inside:(kaseya server public)/5721 ((kaseya server private)/5721)

6          Sep 13 2011          09:54:45          302013          (customer site)          (kaseya server public)           Built inbound TCP connection 146684128493708666 for outside:(customer site)/49315 ((customer site)/49315) to inside:(kaseya server public)/5721 ((kaseya server private)/5721)

Poonguzhali Sankar Tue, 09/13/2011 - 07:32

The only case I ever ran into with Kaseya application is that they set the urgent flag in the packet and we see the following syslogs message causing huge latency/delay issue.

 %ASA-4-419003: Cleared TCP urgent flag from in_ifc:src_ip/src_port to 
out_ifc:dest_ip/dest_port.

See if you see the above syslog and if you DO then implement this workaround.

tcp-map urg-flag
urgent-flag allow

access-list vnc-traffic permit ip any host x.x.x.x

class-map urg-class
match access-list vnc-traffic

policy-map global_policy
class urg-class
  set connection advance-options urg-flag

-KS
felixduivenvoorden Thu, 09/15/2011 - 04:50

KS,

I receive the messages as above:

7 Sep 15 2011 13:28:27  (priv.dest) 5721 (pub source) 32636 Cleared TCP urgent flag from inside:(priv. dest/5721 to outside:(pub.source)/32636

I change my config with the following commando's:

tcp-map urg-flag
  urgent-flag allow


class-map urg-class
match port tcp eq 5721

policy-map global_policy
class urg-class
  set connection advanced-options urg-flag

But this is still receive the error messsage.

in the following link you can see morge information about the same issue.

http://community.kaseya.com/xsp/f/132/p/6771/33206.aspx

Kind Regards,

Felix

Correct Answer
Poonguzhali Sankar Thu, 09/15/2011 - 05:31

That is exactly the problem.  Now, you added the config alright.  Is this applied via a service-policy?

Issue a "clear local x.x.x.x" for the IP address in question and try the connection again.

-KS

Poonguzhali Sankar Fri, 09/16/2011 - 06:27

Felix,

Many thanks for coming back to say that clear local resolved the issue and for rating the thread.

The reaon that the urg flag clear didn't work when you added it to the config is because these inspections and other tcp-maps etc that you configure under the plicy-map gets associated to the local host when it gets created.  I figured the local host was MUST NOT have been created after you added the fix that I provided so, clear local for the IP cleared it and the new local host creation picked up the config urg flag allow config and started to work.

-KS

Actions

Login or Register to take actions

This Discussion

Posted September 12, 2011 at 12:57 PM
Stats:
Replies:8 Avg. Rating:5
Views:2803 Votes:0
Shares:0
Tags: No tags.

Discussions Leaderboard

Rank Username Points
1 7,866
2 6,140
3 3,170
4 1,473
5 1,446