1 Reply Latest reply: Nov 28, 2012 4:50 AM by PhilM RSS

    cannot ping burbs from the secondary firewall after migration



         We recently migrated from an F-series to S4016. The firewall is in an active-standby mode. Everything was migrated and the secondary downloads all the settings of the primary firewall.There are 11 burbs and both firewall can ping each other on its respective burbs. I have tried to ping the firewall interfaces from each burb and I can ping all the interfaces from the primary firewall but there 4 interfaces from the secondary that I cannot ping but I can ping the PC and the primary firewall from the secondary firewall. Below is a log that came from the burb/interface of the secondary firewall that cannot be ping. The traffic source is the PC and the destination is the interface and burb that cannot be pinged. I do not know if the log is related to my concern. Thank you.





      Nov 23 17:45:36 2012 PHT  f_ping_proxy a_proxy t_nettraffic p_major

      pid: 15498 ruid: 0 euid: 0 pgid: 15498 logid: 0 cmd: 'pingp'

      domain: Ping edomain: Ping hostname: fw1.com.ph

      event: proxy traffic end service_name: ping netsessid: 50af45800000f168

      srcip: 10.x.x.x srcburb: internal protocol: 1 dstip: 11.x.x.x

      dstburb: BURB_that_cannot_be_pinged bytes_written_to_client: 0 bytes_written_to_server: 360

      rule_name: Rule name that appeared when I filter the logs cache_hit: 0

      request_status: 0 start_time: Fri Nov 23 17:44:32 2012

        • 1. Re: cannot ping burbs from the secondary firewall after migration

          I have never seen this behaviour before.


          Check the secondary Firewall and make sure that the "Respond to ICMP echo and timestamp" setting has been correctly inherited from the primary's configuration.


          When you run these tests is the PC on the same physical network as the interface you are trying to ping?


          If not then try this first. This will help to isolate whether the problem is linked to the ICMP traffic not arriving or if it is something different.


          A tcpdump could help as you will be able to see if the ICMP echo traffic is arriving in the first place and if there is then a corresponding ICMP echo response to prove that the Firewall is recognising and responding to the ping request.


          Could it be that the switches connecting the two Firewalls is somehow blocking/filtering traffic to these 4 interfaces?


          Trying swapping the cables over and see if the ping problem on these 4 interfaces moves from the secondary Firewall to the primary one. If it does, then I'd suggest that the switch is causing the problem, not the Firewalls.


          Otherwise, given the odd nature of this behaviour, I would recommend that you raise a support request with McAfee technical support.