Skip to main content
rnobili1
rnobili1
New Member
August 14, 2024
Question

FortiOS and SNAT: Excessive reuse of Source Ports

  • August 14, 2024
  • 2 replies
  • 3986 views

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!

2 replies

xshkurti
Staff
xshkurti
Staff
August 14, 2024

@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
    rnobili1Author
    New Member
    August 14, 2024

    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
    pminarik
    Staff
    August 14, 2024

    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.

    rnobili1
    rnobili1Author
    New Member
    August 14, 2024

    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
    Staff
    pminarik
    Staff
    August 14, 2024

    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.

    Terms & ConditionsAccessibility statement