Nmap can scan ports from arbitrary source ports, not just the default 1024+.
Let’s see Nmap in action scanning a target IP 192.168.1.100 for common TCP ports, but originating the scans from source port 443.
sudo nmap -sT --source-port 443 -p 1-1000 192.168.1.100
This command tells Nmap to perform a TCP connect scan (-sT) to target 192.168.1.100. The crucial part is --source-port 443, which forces all outgoing SYN packets to originate from TCP port 443. The -p 1-1000 specifies the range of destination ports to scan.
The problem this solves is simple: many firewalls and intrusion detection systems (IDS) are configured to block or heavily scrutinize traffic originating from low, unprivileged ports (typically above 1023). By scanning from a high, commonly used port like 443 (HTTPS), you can often bypass these basic egress filtering rules. If the firewall allows outgoing traffic on port 443, and the target system has port 443 open, the scan can proceed without being immediately dropped by an intermediate firewall.
Internally, Nmap constructs TCP SYN packets. When you specify --source-port, you’re telling Nmap to set the th_sport field in the TCP header to that value. For a TCP connect scan (-sT), Nmap initiates a full three-way handshake. For a SYN scan (-sS, which requires raw socket privileges), Nmap sends a SYN packet, waits for a SYN-ACK, and sends an ACK. The source port is part of this initial packet.
The key levers you control are:
--source-port <port>: The specific TCP or UDP port you want Nmap to use as the source for its probes. Common choices include 80, 443, 53, or even a port known to be allowed by the firewall.-sT(TCP Connect Scan): This method completes the full TCP handshake. It’s less stealthy but doesn’t require raw socket permissions and works when Nmap can’t craft raw packets.-sS(TCP SYN Scan): This is the default and stealthier method, sending only a SYN packet and interpreting the response. It requires root/administrator privileges.-sU(UDP Scan): Similar principle applies to UDP probes, though UDP is connectionless and responses are less predictable.
Consider a scenario where a firewall blocks all outgoing traffic except for HTTP (port 80) and HTTPS (port 443). A standard Nmap scan from a default source port (e.g., 54321) might be blocked by the firewall before it even reaches the target. By using --source-port 443, Nmap crafts packets that appear to be legitimate HTTPS traffic originating from your machine. If the firewall permits outgoing traffic on port 443, the packets will pass through. The target system will then respond to your IP on port 443. If the target has a service listening on port 443, it will send back a SYN-ACK, and Nmap will see this as an open port. If the target has a different service listening on a scanned port (e.g., port 80), it will still respond to the SYN packet on port 443, and Nmap will interpret the RST (if closed) or SYN-ACK (if open) from the target to determine the port’s status.
The actual response Nmap receives from the target system is what matters. If the target system has port 80 open, it will respond to the SYN packet on port 443 (which Nmap sent) with a SYN-ACK. Nmap sees this SYN-ACK and marks port 80 as open. If the target system has port 80 closed, it will respond with an RST. Nmap sees the RST and marks port 80 as closed. The intermediate firewall only cares that the source port of the outgoing packet is allowed; the target’s response to the destination port is what Nmap analyzes.
When using -sT with --source-port, Nmap will attempt a full TCP handshake from the specified source port. If the firewall allows outgoing connections from the specified source port and the target system has the requested destination port open, the handshake will complete. The firewall might be permissive of outgoing connections from port 443, but it might also be stateful and expect a corresponding incoming SYN-ACK on port 443 if it saw an outgoing SYN from port 443. If the target responds with a SYN-ACK to port 443, the firewall will likely permit it, and Nmap will then complete its handshake on the destination port.
The common pitfall is assuming that just because the source port is allowed, the scan will succeed. The target system’s firewall and its own open ports are still the ultimate deciders. You’re essentially using a permitted egress channel to probe the target’s ingress.
You’ll next want to consider how to handle stateful firewalls that track connections and might drop unexpected responses, even if the source port was allowed.