Troubleshooting Tip: High number Source Port can be blocked by ISP

[dchan]

Description

This article describes a scenario where a high number source port is blocked by the ISP and explains how to resolve it.

Scope

FortiGate.

Solution

Topology:

FortiGate A  ------- FortiGate B -------ISP1 --> ISP2 -----ISP (N) -------- FortiGuard Server.

Problem:

FortiGate A and B are in NAT mode. FortiGate B has no problem communicating with the FortiGuard Web filter server in Port 53 or Port 8888. However, FortiGate A has a connectivity issue with the FortiGuard web filter server.

Running the packet sniffer on the FortiGate unit shows:

• Source Port 1028, Destination port 53 or 8888 
• Packet sniffer from Fortigate B (AFTER NATTing) showed: 
• Source Port 36000, destination port 53 or 8888

Packets left FortiGate B with a high source Port, but no return packet from the FortiGuard server. Sniffing packets from the FortiGuard server does not show any request packets arriving, proving that packets are being blocked by the ISP.

Each ISP has its own routing and access policy, so it is possible that a high source port is being blocked by any given ISP.

To solve the issue:

Use a fixed-port on the NATed firewall policy on FortiGate B. This way, low source ports initiated by FortiGate A will not be changed after NATing on FortiGate B. Packets will remain with the low source ports. For an article describing the use of fixed-ports, see Technical Tip: Using 'set fixedport' or 'Preserve source port' in a firewall policy.

For a FortiGate 6000/7000 Series Chassis, the NAT source port decision works slightly differently from a general FortiGate:
Technical Tip: Understanding NAT port allocation on Chassis (6000 and 7000 Series) 

Related articles:

• Technical Tip: How to preserve source port when central NAT is enabled 
• Fine-tuning source port behavior for SNAT 
• Troubleshooting Tip: Using the FortiOS built-in packet sniffer for capturing packets