pfSense

Please find attached the packet capture reduced down to just ICMP traffic. The associated firewall rule is:

pass  in  quick  on $WAN2_DSL reply-to ( igb2 <gateway> ) inet proto icmp  from any to <WANsubnet> icmp-type echoreq tracker 1464807726 keep state  label "USER_RULE" 

I have filtered the pcap down to just the ICMP packets (so you can see the ping responses, timestamp responses, but no address mask responses).

The pcap was taken without any other filtering so if other traffic being sent is relevant, I can forward to you the whole pcap (1.8MB)

• All ICMP QIDs selected (including ICMP Mask Reply, ICMP Timestamp Request, ICMP Replies Received)
• Scan range of 198.51.100.4-198.51.100.6
• No TCP/UDP scanning

The firewall rule used was:

pass  in  quick  on $ISP1 reply-to ( vmx0.99 198.51.100.1 ) inet proto icmp  from any to 198.51.100.0/24 icmp-type { echoreq,timex,trace,unreach }  !  tagged "blocklist" ridentifier 1529162985 keep state label "USER_RULE: ping to firewall" label "id:1529162985" 

pcap:

No.    Time    Source    Destination    Protocol    Length    Info
411    48.200547    64.39.98.10    198.51.100.5    ICMP    60    Echo (ping) request  id=0x90ab, seq=37035/43920, ttl=54 (reply in 412)
412    48.200642    198.51.100.5    64.39.98.10    ICMP    50    Echo (ping) reply    id=0x90ab, seq=37035/43920, ttl=64 (request in 411)
413    48.369620    64.39.98.10    198.51.100.5    ICMP    60    Timestamp request    id=0x3be3, seq=2931/29451, ttl=245
414    48.391532    64.39.98.10    198.51.100.5    ICMP    90    Echo (ping) request  id=0x3bef, seq=15343/61243, ttl=245 (reply in 415)
415    48.391581    198.51.100.5    64.39.98.10    ICMP    90    Echo (ping) reply    id=0x3bef, seq=15343/61243, ttl=64 (request in 414)
416    50.371693    64.39.98.10    198.51.100.5    ICMP    60    Address mask request id=0x3be3, seq=2931/29451, ttl=245
417    53.396186    64.39.98.10    198.51.100.5    ICMP    95    Echo (ping) request  id=0x3bef, seq=28346/47726, ttl=245 (reply in 418)
418    53.396224    198.51.100.5    64.39.98.10    ICMP    95    Echo (ping) reply    id=0x3bef, seq=28346/47726, ttl=64 (request in 417)
419    56.376805    64.39.98.10    198.51.100.5    ICMP    60    Timestamp request    id=0x3be3, seq=2931/29451, ttl=245
420    58.379240    64.39.98.10    198.51.100.5    ICMP    60    Address mask request id=0x3be3, seq=2931/29451, ttl=245
573    64.384944    64.39.98.10    198.51.100.5    ICMP    60    Timestamp request    id=0x3be3, seq=2931/29451, ttl=245
632    66.386656    64.39.98.10    198.51.100.5    ICMP    60    Address mask request id=0x3be3, seq=2931/29451, ttl=245

Either this does not affect 23.01/2.7, or there's something specific to the environment in the reported cases. I'm going to mark this as Not a Bug until it can be reproduced.

Hiya Marcos,

We've just reproduced this on a totally stock PFsense 2.6.0 install. The only things we did was to configure an IP alias to add a second address and add the firewall rule. I'm attaching the backup of the configuration (config-TESTpfSense.home.arpa-20230124161406.xml).

We scanned using 81.143.222.156-81.143.222.157 as the range in Qualys. I've attached the bottom part of the report so you can see the scan options we used (Scan_profile.html). As this is a test box I have also included the entire packet capture (Scan_2023-01-24_16-19-36.pcap) which shows (packets no 1179, 1180, 1189,1190) timestamp requests and timestamp responses. You can also see addressmask requests however they are not responded to.

We're going to upgrade to a 2.7.0 snapshot now and see if the problem is still reproducable.

Thanks,
Rob

Hello,

We have just tested pfSense-CE-memstick-2.7.0-DEVELOPMENT-amd64-20230125-0600.img.gz and we are seeing the ICMP timestamp responses on there as well.

We have attached the backup of the 2.7.0 configuration (config-testpfsense.home.arpa-20230125115540.xml) so you can see the rule that's added etc, it's basically identical to the 2.6.0 configuration uploaded yesterday.

I have also attached the pcap of all the traffic so it can be verified that there are ICMP timestamp responses.

The target of the scan was: 81.143.222.156-81.143.222.157

The option profile within Qualys was as follows:

Title:
DEFAULT_VM_OPTIONS_PROFILE_2022
Options:
Standard TCP port list and Additional TCP Port List : 8080, 8081, 8082, 8083, 8084, 8085, 8090, 50000, 50001, 50003, 33848, Standard UDP port list and Additional UDP Port List : 8080, 8081, 8082, 8083, 8084, 8085, 8090, 50000, 50001, 50002, 33848, parallel ML scaling disabled for appliances, Load balancer detection ON, Intrusive Checks: Excluded, Windows Authentication ON, Unix Authentication ON, SNMP Authentication ON, VMware Authentication ON, HTTP Authentication ON, Ignore firewall-generated RST packets, Ignore firewall-generated SYN-ACK packets, Custom Host Discovery TCP Port list and Additional Host Discovery TCP Port list 21-23, 25, 53, 80, 88, 110-111, 135, 139, 443, 445, 1433, 1521, 1525, 1526, 1527, 1529, 1571, ICMP Host Discovery, Overall Performance: Normal, Allow Parallel Scanning: Disabled, Hosts to Scan in Parallel - External Scanners: 15, Hosts to Scan in Parallel - Scanner Appliances: 30, Total Processes to Run in Parallel: 10, HTTP Processes to Run in Parallel: 10, Packet (Burst) Delay: Medium, Intensity: Normal

I am currently getting our Qualys guys to configure a profile that is ICMP checks only, so we can see if the issue only occurs with mixed traffic (which is my hunch).

I will report back if we get any more information.

Thanks

Hiya,

So we think we have got this down the smallest scan we can (takes about 90 seconds). There unfortunately isn't a way of exporting or saving the policies out of qualysguard.qg2.apps.qualys.com; so I've hit "view" and saved the HTML of the profile. It's not the cleanest/easiest to read however all the settings are there. Myself and someone else set up two different scans in Qualys, mine didn't show the problem, his did. Turned out that I had ticked "Include dead hosts in scans" and "Enable host alive testing". That combination made the scan not report it back.

We have also attached the traffic capture using that profile (which is much smaller than the others as you would expect) which was run 139.87.112.105 (Scanner 12.12.48-1, Vulnerability Signatures 2.5.684-2)

Just to clarify, we are running from the Qualys Cloud Platform, not from any on-prem agent or anything.

Thanks,

• A Search List with the 82003 ICMP Timestamp Request QID.
• An Options Profile with Host Discovery: ICMP turned on; all other tests/scans/options disabled (in particular, Include dead hosts in scans and Enable host alive testing).
• A consecutive target range (confirmed it fails with a single host as the target).

On pfSense, allow ICMP echo requests (needed for the scanner to detect the host and subsequently run the timestamp scan), and block all other ICMP:

pass  in  quick  on {  vmx0.99  } reply-to ( vmx0.99 198.51.100.1 ) inet proto icmp  from any to 198.51.100.0/24 icmp-type echoreq ridentifier 1675104047 keep state label "USER_RULE: testa" label "id:1675104047" 
block  in log  quick  on {  vmx0.99  } reply-to ( vmx0.99 198.51.100.1 ) inet proto icmp  from any to 198.51.100.0/24 ridentifier 1675103204 label "USER_RULE: testb" label "id:1675103204" 

Packet capture of scan:

No.    Time    Delta    Source    Destination    Protocol    Length    Info
987    97.946388    0.008637    64.39.98.3    198.51.100.5    ICMP    60    Echo (ping) request  id=0x0000, seq=0/0, ttl=246 (reply in 988)
988    97.946412    0.000024    198.51.100.5    64.39.98.3    ICMP    42    Echo (ping) reply    id=0x0000, seq=0/0, ttl=64 (request in 987)
1055    99.849817    0.030909    64.39.98.3    198.51.100.5    ICMP    60    Echo (ping) request  id=0x4bc5, seq=19755/11085, ttl=246 (reply in 1056)
1056    99.849844    0.000027    198.51.100.5    64.39.98.3    ICMP    42    Echo (ping) reply    id=0x4bc5, seq=19755/11085, ttl=64 (request in 1055)
1103    101.850952    0.102859    64.39.98.3    198.51.100.5    ICMP    60    Timestamp request    id=0x4bc5, seq=19755/11085, ttl=246
1104    101.850965    0.000013    198.51.100.5    64.39.98.3    ICMP    54    Timestamp reply      id=0x4bc5, seq=19755/11085, ttl=64
1169    103.853321    0.045354    64.39.98.3    198.51.100.5    ICMP    60    Address mask request id=0x4bc5, seq=19755/11085, ttl=246
1253    109.860308    0.176726    64.39.98.3    198.51.100.5    ICMP    60    Address mask request id=0x4bc5, seq=19755/11085, ttl=246
1300    115.866207    0.023488    64.39.98.3    198.51.100.5    ICMP    60    Address mask request id=0x4bc5, seq=19755/11085, ttl=246

I've created a separate report with specific details and easily reproducible steps; I'm going to close this one out and link it as a related issue.