Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
rnobili1
New Contributor

FortiOS and SNAT: Excessive reuse of Source Ports

Hello,

 

I have devices in LAN (APs) that creates two connections to the same Public IP (CAPWAP Control Channel: UDP/5246 + CAPWAP Data Channel UDP/5247)

 

Both connections have the same port as Source Port: 5270, this is the behavior I get with FortiOS 7.2:

 

G9mwwhF

--> The Gate is assigning the same SRC port (5270) to two different flows intended for the same IP target (where, however, the destination-port differs)

 

I realized that surely this comportment is the child of how FortiOS selects unused NAT ports,
but do you think there is a configuration that would allow me to have SOURCE PORT was Always changed for an SPECIFIC DESTINATION?

 

The Host on the on the other hand side is not able to distinguish the traffic if it comes from Capwap-DATA or Capwap-CTRL if it comes from the same src-port (and obviously same src-ip)

But now that we know the Host Target limitation, my question is how can I change the port assignment logic in SNAT on my FortiGate

 

Thanks!

9 REPLIES 9
xshkurti
Staff
Staff

@rnobili1 
You create 2 different firewall policies where you specify first source for first traffic and second source for second traffic.

What I would suggest doing is to create an IP Pool for the outbound traffic.

That way you get a little more control of the source NAT which might help and avoid the session clash

rnobili1

The Server constraints are:

  1. Does not support CAPWAP packets from different APs arriving at WLC with same source IP:port.
  2. Does not support CAPWAP packets from same AP arriving at WLC with different source IP.
  3. Does support CAPWAP packets from same AP arriving at WLC using same source IP and different source port as long as one single source port is used for data and another single source port is used for control

So I don't think this IP Pools solution solves my problem.

The second question I ask is whether this "reuse" behavior of the source port is normal or not.

pminarik
Staff
Staff

SNAT-ed sessions are tracked per SNAT source IP, source port, protocol (TCP/UDP), destination IP, and destination port. All of that.

If the destination port is different, the FortiGate can and will use the same SNAT IP:port without problems and without session clashes. It is also worth noting that even when you don't have "preserve source port" enabled, the FortiGate will try to preserve it unless it would lead to a clash, as long as it's not a low-numbered privileged port (<1024, or something along those lines, I don't remember exactly)

 

tl;dr: working as expected.

 

Consider applying an IP pool with port-ranges ("fixed port range" or "port block allocation") assigned to a firewall policy just for this specific traffic. The port-ranges will ensure that the SNAT source-ports are shifted into different port ranges.

[ corrections always welcome ]
rnobili1

Yes, fixed port is disabled: https://i.imgur.com/NkGjasH.png

I have is not having one session to the target (I have cases where +150 access points that need to be natted behind the same Public IP = 300 CAPWAP sessions vs same Public IP with same Local Source Port).

 

So, the WLC on the on the other hand side is not able to distinguish the traffic if it comes from Capwap-DATA or Capwap-CTRL if it comes from the same src-port (and obviously same src-ip)

But now that we know the Host Target limitation, I'm trying to figure out if there's a way around this behavior

pminarik

The basic SNAT behaviour is not configurable. Take-it-or-leave-it.

 

Try the IP pool approach that I suggested.

 

edit: And honestly, I would recommend chasing the WLC vendor, because clearly they don't support general NAT of traffic properly. They should be the ones primarily fixing their own mess up.

[ corrections always welcome ]
rnobili1


@pminarik wrote:

Consider applying an IP pool with port-ranges ("fixed port range" or "port block allocation") assigned to a firewall policy just for this specific traffic. The port-ranges will ensure that the SNAT source-ports are shifted into different port ranges.


Can you explain this point better? Keep in mind that I must always present my "Natted Devices" to the Target-IP with the same Public IP for both Services (Capwap CTRL = UDP/5246 + Capwap DATA = UDP/5247)

 

Thanks!

pminarik

This type of IP pool will assign port-ranges to individual LAN clients.
LAN-1 -> srcports N ~ N+100

LAN-2 ->srcports M ~ M+100

etc.

 

This should in theory naturally ensure that two APs don't share the same SNAT port across different sessions to WLC's different destination ports.

 

-----------------------

 

One more idea. If you want to try something fancy, you can try using VIPs to force static SNAT. Ref: https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-use-a-VIP-s-External-IP-Address-for...

 

This will only work if your APs can be statically configured to use one specific source-port for the traffic, different for each.

 

VIP: <WLC>:<CAPWAP-port-X> -> <AP-LAN-IP>:<static-srcport>
- repeat for each AP
- Add it into a deny policy in the WAN->LAN direction (won't do anything, except trigger the desired SNAT behaviour; all VIPs can be in a single policy)

- ensure that the AP->WLC traffic passes through a LAN->WAN (reverse to the VIP) policy with basic SNAT ("using egress interface IP").

[ corrections always welcome ]
rnobili1

All APs always use the same Source Port (UDP/5270) for both CAPWAP CTRL+DATA flows and I can't change it.

 

The solution of assigning small pools of src-ports for each individual IP LAN Client seems fine, Could you give me some links that explain how to configure this?

pminarik

Samples for both IP pools are shown here: https://docs.fortinet.com/document/fortigate/7.4.4/administration-guide/29961/dynamic-snat

[ corrections always welcome ]
Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors