Nihas
New Contributor

Port Block Allocation Errors

Hi, I just want to know why I am getting the PBA -exhaust -alert every now and then. I have not configured PBA, and I am using One to One mapping NAT. Is this normal? thanks
Nihas [\b]
3 Solutions
Adrian_Buckley_FTNT

Port exaustion occurs when the FortiGate can't open a particular port, for NAT.

 

When traffic passes through the FortiGate it has a source/destination port.

IE:  10.10.10.10:3345->192.168.1.5:80

 

When the FortiGate does NAT, that source port (3345) gets randomized so the new packet becomes (interface IP):(random port)->192.168.1.5:80

This is also how a reply packets from different internal hosts are figured out(2 people going out will use the same source IP but use different source ports).

There are 65,000 ports per IP and the FortiGate reserves half for TCP and half for UDP.

 

If you use fixed port on your NAT policies and then the FortiGate won't be allowed to change the source port.  So 2 packets with the same source port will cause this.

 

Some firmware versions have had bugs with this, so try looking at the release notes for new versions.  I can't remember which versions were effected.

If the message is not in error, then you're hitting the transfer limits.  Lowering session timers could help, or setting up multiple outbound IPs through an IP pool would be options.

View solution in original post

Adrian_Buckley_FTNT

Any time the FortiGate does a NAT operation (source IP, or destination IP) the traffic source port is randomized (by default), which means you can run into this.  You can enable fixed port on the policy to prevent the randomization but obviously this is not recommended since 99% of software won't care or notice.  The Fixed port setting can be the cause of this message as well so if you have it enabled, turn it off.

 

Reducing session timers can also help since it will clear out sessions faster.

 

I'd also suggest upgrading to a newer 5.0 patch.  I do recall there was a bug in the FortiGate firmware about nat port exhaustion not that long ago, but i don't remember exactly which versions were effected.

 

Failing that, if this behavior is not the cause of a bug or setting, then it means you need more IPs to nat traffic onto.

 

 

 

 

 

View solution in original post

ede_pfau
Esteemed Contributor III

For port exhaustion to happen even with just 1 public address you would need more than 64000 sessions alive at that time. I doubt that this is the case.

Nihas, can you tell how many sessions you see at maximum? Does it come close to >50K?

If not I bet this error is not really caused by the circumstances but rather by a bug in v5.0.5. I recommend to update to 5.0.9 soon to see if this has an influence.


Ede

"Kernel panic: Aiee, killing interrupt handler!"

View solution in original post

12 REPLIES 12
ede_pfau
Esteemed Contributor III

I' d be more concerned by " session clash" messages...no, this is not normal. Given that the FG310B is not a paper tiger running out of ressources easily, there' s something wrong with the setup. It might have to do with the cluster setup - did you check that it' s fully sync' ed? (diag ha csum or the like). Which version of FortiOS?

Ede

"Kernel panic: Aiee, killing interrupt handler!"
Nihas
New Contributor

Thanks Ede, Sorry for the late reply. Yea, We were using a HA Cluster and everything was fine except data traffic speed between IPSec tunnels networks. Means, if I want to copy a 20MB file from other location, it started taking a lot of time and traffic rate was like below 20 KB/s. And unfortunately we didn' t find any issues with the HA configuration ( Like checksum was same in 2 boxes, and failover was working ) . So we end up with the troubleshooting by cursing the switch we used to setup Cluster. :) It was a cisco SMB SG300 switch and we have created 4 VLANs ( 3 for ISP' s and 1 for LAN) So the Cluster has only one box now. I can give you more details if you want to verify.
Nihas [\b]
ede_pfau
Esteemed Contributor III

So you say that the switch slowed down your VPNs to 20 KBps?? How that?

Ede

"Kernel panic: Aiee, killing interrupt handler!"
Nihas
New Contributor

Hi Ede, Frankly , we didn' t find the root case actually. Sorry to say ,We were assuming that it might be something related with the Switch. And we are planning to put a switch for the Cluster to isolate the issue, I can involve you while doing that, but date is not yet confirmed. Btw, Can you guide me, is that a best practise to use a single switch to do the HA. I have 3 ISP and 1 Internal network . Thank you very much for all your help. Best , Nihas
Nihas [\b]
ede_pfau
Esteemed Contributor III

Well, best practice is not to have a single point of failure. If your single switch (VLAN segmented) is a Nexus with dual PSU I' d say you can risk it. For lower budgets I have used single desktop switches with 8 ports for each port in use (fgt1, fgt2, network, test) like Netgear Smart Switch GS-108Tv2. They have nice features like VLAN, LACP, a WebGUI etc. I have yet to see one fail in a couple of years now.

Ede

"Kernel panic: Aiee, killing interrupt handler!"
Dave_Hall
Honored Contributor

Just curious to know if there is a duplex/speed mismatch somewhere or central NAT has been enabled?

NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C

Nihas
New Contributor

hello Dave,

No, we are simply using one to one Nat , and nat central table is not enabled.

 

Nihas [\b]
Adrian_Buckley_FTNT

Port exaustion occurs when the FortiGate can't open a particular port, for NAT.

 

When traffic passes through the FortiGate it has a source/destination port.

IE:  10.10.10.10:3345->192.168.1.5:80

 

When the FortiGate does NAT, that source port (3345) gets randomized so the new packet becomes (interface IP):(random port)->192.168.1.5:80

This is also how a reply packets from different internal hosts are figured out(2 people going out will use the same source IP but use different source ports).

There are 65,000 ports per IP and the FortiGate reserves half for TCP and half for UDP.

 

If you use fixed port on your NAT policies and then the FortiGate won't be allowed to change the source port.  So 2 packets with the same source port will cause this.

 

Some firmware versions have had bugs with this, so try looking at the release notes for new versions.  I can't remember which versions were effected.

If the message is not in error, then you're hitting the transfer limits.  Lowering session timers could help, or setting up multiple outbound IPs through an IP pool would be options.

Nihas
New Contributor

Thanks Adrian for the excellent explanation.

 

So Is the port block Or reservation happens in One to One NAT also? 

The box is running on 5.0.5. 

 

Nihas [\b]