I noticed that since going live, our Kaseya server is unable to get out to update itself. After doing some troubleshooting, I'm thinking that the problem is likely because we have our dynamic PAT rule in place for web surfing. Since the updates need to connect to the url at port 5721, I think that that is making such a connection impossible.
So the question is two fold: One, how to configure a NAT rule to not use the PAT and instead allow port 5721? When I have tried going from that specific server out to the ipaddress and specifying the port, it still doesn't work. Of course, we are on a non-routable internal network, so I assume that it would have to translate to a routable IP. Would that be two different rules?
Also, is the dynamic rule going to keep causing issues like this? So far we don't seem to have a lot of them, but I have been curious from the start about whether the dynamic NAT statement might make things more difficult due to the lack of consistency.
The destination port does not change during a NAT or outbound PAT. A couple of things to check 1) is the ACL allowing port 5721 to the update server? 2) has the IP of the update server changed? 3) Is the ACL hit counts increasing when you try an update the server?
Let us know what happens.
FYI - Check out the built in packet tracer. I ignored the tool for awhile thinking I was smarter than it, but I sat down one day and learned it. It is now one of my favorite troubleshooting tools for the ASA. It will tell you exactly what is wrong (but not how to fix it (yet)). Here's a training snippet on it.
I did the tracer yesterday when I made changes and it indicated it should work. Today, however it is saying that it fails on "Nat Lookup". This lends more weight to my theory that perhaps I need to configure a NAT rule for this. I have an access rule specifically to allow port 5721 (I'm not actually not entierly sure where that rule belongs? Inside in? Outside in? I ahve it on both places atm to cover my bases)
If you are connecting to a specific port with PAT, does it come back on that same port? I was under the impression that the dynamic quality of a PAT was that it might open X port, but that it was short lived and somewhat flaky for non-immediate return traffic. Also, that obviously since the port connection was dynamic, that it didn't work for a specific port?
Collin is correct in what he says in that PAT does not modify the destination port, only the source port so that will not be the issue.
However from your packet tracer test it suggests that the source port also needs to be 5721 ?
You need to work out whether the application you are using needs to have the port set to 5721 on both ends. If it does then you cannot use PAT, you will need a static NAT for that server. Some applications do indeed have this requirement although they are rare.
If it doesn't then PAT should work fine. PAT builds entries dynamically but it does not remove the entries it creates until the connection is finished so that will not be the problem.
Also the acl you referred to, it would be applied on the inside interface, inbound allowing your server IP to connect to destination IP/port number 5721. However if you don't have an acl applied to the inside interface already then traffic will be allowed anyway.
You don't need to add anything to the outside acl as the traffic is allowed back in automatically because the ASA is a stateful firewall.
I will need to contact Kaseya and see if both ports need to be the same. I'm kind of thinking that that is going to be the case, since nothing else I
have tried has worked. Is there anyway to do a PAT exception so that it does not get given a dynamic port?
If not, what would be the best way to configure an outgoing static NAT rule? I have been a little unsure about whether or not a dynamic PAT was the best solution for our needs due to its unpredicitibility. I have left it alone so far because I've been learning all the other stuff as fast as I can. However, this might be the signal that we should switch before too much is set in stone.
(Interestingly, I've noticed for ICMP, I have to have a rule on both or it won't work.)
I have a fairly open rule to test with that is an any, any port 5721 rule in place. Right now it has 4 hits on it....so I'm not sure what that means. When I run the "get update" thing, the count does not increase. So, not exactly sure where those few hits are coming from.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :