This topic is to discuss the following lesson:
what do you mean by “the connection rate” ? the connection rate is about 2000 per second
Hi John,
With multi-session PAT you can have about 2000 connections using one IP address for PAT, this is because of the 30 second timeout. With per session PAT we don’t have this timeout so we can have a lot more connections using the same public IP address.
Rene
Is there any reason why you would use multi-session PAT rather than Per-Session PAT, or vice versa?
Never mind, I found it in your article.
Hi
I am running ASAv version 9.6.
when I run the command “show run | in xlate per-session”, the output is showing all deny rules. But in your output it is showing all permit. Any idea why I am seeing all deny
ASAv# show run | include xlate per-session
xlate per-session deny tcp any4 any4
xlate per-session deny tcp any4 any6
xlate per-session deny tcp any6 any4
xlate per-session deny tcp any6 any6
xlate per-session deny udp any4 any4 eq domain
xlate per-session deny udp any4 any6 eq domain
xlate per-session deny udp any6 any4 eq domain
xlate per-session deny udp any6 any6 eq domainDoes this mean that by default Multi-Session PAT is enabled on my firewall?
Hmm I think it depends on your platform and/or ASA version. Here’s a 5506 running ASA 9.5 with a fresh config:
ASA# show running-config all | include xlate
xlate per-session permit tcp any4 any4
xlate per-session permit tcp any4 any6
xlate per-session permit tcp any6 any4
xlate per-session permit tcp any6 any6
xlate per-session permit udp any4 any4 eq domain
xlate per-session permit udp any4 any6 eq domain
xlate per-session permit udp any6 any4 eq domain
xlate per-session permit udp any6 any6 eq domain
Per-session is enabled by default. With your deny statements, multi-session PAT is enabled yes.
I think it would be helpful to hear some of the other use cases for Multi-Session PAT. Surely there are other reasons other than Voip?
Also, what is the danger to voip traffic? I know that I have several fully functioning Voip deployments in the wild that ended up behind ASAs that I don’t manage myself, and I know they don’t use multi-session PAT. Voip traffic seems to pass just fine as I’ve had no complaints.
Hello Chris
Multi-session PAT is the default configuration within an ASA device. Any PAT translations that exist are kept open for 30 seconds before being flushed out. The reason for this is that it takes CPU power and resources to tear down and to reinitialize a PAT translation, so if a session that has ended restarts sending using the same translation and ports within those 30 seconds, there is no need to re-establish the connection, the translation already exists.
Per-session PAT is an improvement to this default because it quickly frees up translated ports, thus allowing them to be immediately available for use by new sessions. This is especially useful when you have a single external IP address that is being shared by a large number of internal hosts each running a multitude of applications. It results in a more efficient use of the available ports for use with PAT.
Now there is a problem with such a setup especially for real-time applications such as voice and video. A voice session for example, will have several packets being exchanged when users are talking, however, when both stop talking for any period of time, no new packets are exchanged. The Per-session configuration will consider such a case a terminated session and will tear down any translations that may exist. The users however continue talking, packets are exchanged, and new translations must be established. This takes time and resources and can cause disruptions in the voice conversation. Due to the nature of voice and of human speech, this can result in multiple re-establishments of translations causing an increase in resource usage as well as disruption in the voice conversation.
It is for this reason that VoIP sessions should be exempt from any per-session PAT and should remain under the default Multi-session PAT configuration.
I hope this has been helpful!
Laz
4 Likes
Thanks for the info.
1 Like
Cud you kindly put that exemption command for voip/video here?
How can we distinguish voice/video traffic to deny them from xlate?
Hello Erik
A clarification on my previous post. Multi-session PAT is the default on Cisco ASA devices before version 9.x, because it was the only type of PAT available. On ASA 9.x and later, Per-session PAT is enabled by default.
Now in order to disable per-session PAT and enable multi-session PAT, you will have to use the following commands (as stated in the lesson):
ASA1(config)# no xlate per-session permit tcp any4 any4
ASA1(config)# xlate per-session deny tcp any4 any4
Remember that a permit rule uses per-session PAT, and a deny rule uses multi-session PAT. So in the above example, per-session PAT is disabled for everything and multi-session is enabled for everything. If you want to do this selectively for SIP for example, you can use the following command:
xlate per-session deny tcp any4 any4 eq 5060
This will enable multi-session PAT for any TCP communication with a destination port of 5060, which is the port used for unencrypted SIP signalling. You can further specify sessions by indicating source and destination IP addresses, other transport layer protocols or source and destination ports.
More information on this command can be found here:
I hope this has been helpful!
Laz
4 Likes
Hello Shriram
Can you tell us a little more about your difficulty? Is it with the per-session or multi-session PAT that you cannot telnet? Can you ping? Are the translations taking place? I suggest you follow these troubleshooting steps:
- For (normal) per-session PAT, make sure that translations are taking place. Try pinging to see if you get a response, and check that NAT is indeed translating. If you’re not able to ping, troubleshoot the NAT configuration and connectivity in general.
- If you are able to ping but you can’t telnet, then check the telnet configuration and make sure that it is correct.
- Once you get it working, follow the same steps for multi-session PAT.
Following these steps, you should be able to pinpoint the problem more accurately. If you still have issues, let us know your results so we can help you further in your troubleshooting process.
I hope this has been helpful!
Laz
1 Like
Hi Laz,
Its working now…
Thanks for help!!
1 Like