When running external Scans I am having difficulty trying to pinpoint where the internal vulnerability is due to Nat'ing Issues, is there anyway of getting around this?
In most cases you should not "see" the real internal address in external scan results.
The best to find the hosts is to scan them from the inside as well or perhaps review firewall configs to understand nat'ing and allow rules.
Depending upon the firewall configuration, host configuration, and routing... a number of things could be going on.
Start by inspecting the network infrastructure and component configurations and logs. The routing table of the inside asset being scanned is also a good place to look. Verify it has the correct route back to the scanner.
Also, note that the best way to avoid NAT issues is to avoid the scenarios that use NAT.
If it is not an external compliance scan, perhaps try to utilize internal scan appliances on the same VLAN as the scanned resource so NAT is not in play and only local subnet routes are involved.
It's not recommended, but some enterprises use a source NAT on the inbound traffic to an IP the inside host asset has a route to (such as an IP in the same subnet as the system being scanned)
Avoiding the use of port address translation (PAT) and using 1:1 NATs for the inbound and outbound traffic will frequently provide more repeatable results.
This issue with PAT is related to its architecuture. If a PAT pool starves of ports (session count approaching 65K in the NAT table for the PAT IP) it can cause the firewall to start dropping traffic thats required to go through the PAT.
If the problem does turn out to be pool starvation, occasionally simply adjusting the timeouts on the existing PATs or NATs is all that is necessary to resolve the problem.
Have a great day!
Retrieving data ...