Blocking a constant wan ping



  • Hello,

    I have what a DNS lookup calls a private IP hitting my WAN, 24 hrs a day sometimes up to 3 times a second. This has been going on now for over 2 weeks. My Firewall logs are a constant stream of this IP. I have the IP block and also the port they are using. Is there anything else I can do to stop this? Or being I have it blocked, do I need to do any else at all. I would like to stop the logging of this IP.

    I am running i386 PfSense 2.0 RC3 with the latest updates.

    Thanks



  • Disable the checkbox "block RFC1918" on the WAN-config page.
    Create an alias containing 10.0.0.0/8, 172.16.0.0/12 and 192.198.0.0/16.
    Create on your WAN a new block-rule with as source any and as destination the previously created alias.

    You now have the same functionality but without entries in the log.


  • LAYER 8 Global Moderator

    Seems odd that you would be seeing traffic from a private IP, unless coming from your isp network.  Or if you pfsense is behind a nat or something and something sitting between the pfsense box and actual internet.

    Private IPs are 10.x.x.x, 172.16-31.x.x, 192.168.x.x

    if coming from one of those IPs, would you mind posting a network capture of the traffic and posting it.  You mention port, and then ping - but ping does not use a port.

    You can do a capture on your wan port on pfsense under diagnostics.



  • @johnpoz:

    Seems odd that you would be seeing traffic from a private IP, unless coming from your isp network.  Or if you pfsense is behind a nat or something and something sitting between the pfsense box and actual internet.

    Private IPs are 10.x.x.x, 172.16-31.x.x, 192.168.x.x

    if coming from one of those IPs, would you mind posting a network capture of the traffic and posting it.  You mention port, and then ping - but ping does not use a port.

    You can do a capture on your wan port on pfsense under diagnostics.

    I am new to PfSense, Ping may have been the wrong word to use. After starting a package capture and then downloading it, How do I open it? I using the web gui on a windows machine.



  • This is an example of what my firewall log looks like.

    ![firewall log.jpg](/public/imported_attachments/1/firewall log.jpg)
    ![firewall log.jpg_thumb](/public/imported_attachments/1/firewall log.jpg_thumb)



  • Thats your cable company's router hitting your box…  They use addresses usually in that block to admin the modems...  I had to do what GruensFroeschli instructed above to stop the logs on my box...


  • LAYER 8 Global Moderator

    Admin modems?  That is dhcp traffic, port 67 to port 68 is DHCP.

    out to broadcast address of 255.255.255.255, I would contact your ISP they have something flooding the network with dhcp.

    From that info I can not tell if offer or ack.  It has source IP, and source port of 67 so it has to be either off or ack.

    Post up a capture and we can tell if offer or ack.

    But i would not suggest you just not log it, I would suggest you contact your ISP to fix it!  Or for that matter it could be your box causing it? Once we get a capture of the data we will have more info.

    To view the capture, grab http://www.wireshark.org/ its FREE protocol analyzer, and you can view the details of those dhcp packets.

    edit, ok did a quick capture on my wan for a dhcp packet to 68.  Now this one was ACK, and lots of info in it.. What the client IP was, the netmask, the gateway(router) what the ip of the actual dhcp server was and not the relay that is show as source IP, etc. etc.

    If you post up your capture we should be able to tell if just really really busy network with dhcp, or if you have some client causing issues, or if sending out same ack, etc.  This is just one packet, your getting some every few seconds I would capture say 50 or 100 of them and post up your capture and we can take a look.  Just put 68 in as your destination port so we don't get any other traffic other than this dhcp.

    Worse case is we would get you IP address?  But I doubt its your box causing the issue, so just get other client IPs on your same ISP segment..  For example this is not my network, my network is 24.13.176.x

    edit2:  Just so you would have something to compare with, I did a 2 minute capture on my wan for dhcp (port 68) and I saw 12 whole packets in that 2 minutes…  Your seeing way more more than that for damn sure, but before you go and just not log it I would take a look to see if legit just lots of clients, etc.  or if something is wrong.  Can not do that until we take a look see with a capture.  See 2nd attachment for the 12 dhcp packets.





  • LAYER 8 Global Moderator

    Its is NOT his cable company router – its typical dhcp chatter.  I have seen the captures.



  • The simplest solution…
    goto: Status:-> System logs:-> Settings
    untick: "Log packets blocked by the default rule"



  • You can stop the logging temporarily while you report the problem to your ISP. I would only block the ip address that is flooding so that you can see other issues that might be hitting your network. Once fixed, then you can remove the non-logging block rule.


  • LAYER 8 Global Moderator

    Not a flood, its a bunch of different boxes dhcp – its common dhcp traffic that you would see on any network.

    He emailed me the captures - its not one host with an dhcp issue, its just common dhcp chatter..  He is seeing cable modems and clients, its offer and acks from the isp dhcp server to its clients.

    The dhcp relay is 10.226.64.1
    and the actual dhcp server is 172.21.0.32

    He is seeing a bunch of stuff on his lan as well, because he tweaked his lan rules other from the default allow any, rules are wrong, etc.

    But he has not answered if he is still seeing them..  from my it looks like dhcp should be allowed and not logged, before the private lan rules, so I think something is out of order

    So if reading this right, pfctl -sr output from mine, have not gotten his output yet - but asked him in email

    block drop in log quick on re1 inet from 10.0.0.0/8 to any label "Block private networks from WAN block 10/8"
    block drop in log quick on re1 inet from 127.0.0.0/8 to any label "Block private networks from WAN block 127/8"
    block drop in log quick on re1 inet from 172.16.0.0/12 to any label "Block private networks from WAN block 172.16/12"
    block drop in log quick on re1 inet from 192.168.0.0/16 to any label "Block private networks from WAN block 192.168/16"
    block drop in log quick on re1 inet6 from fc00::/7 to any label "Block ULA networks from WAN block fc00::/7"
    pass in on re1 proto udp from any port = bootps to any port = bootpc keep state label "allow dhcp client out WAN"
    pass out on re1 proto udp from any port = bootpc to any port = bootps keep state label "allow dhcp client out WAN"

    The rules below go first???  So broadcast to 67 and 68 should be passed should it not, and not logged even if from private??  So why is he logging this traffic.

    Again that is output of my pfctl -sr, have not gotten his yet.  We got on a bit of tangent with talking about his storage 24TB, pretty sweet and some of his other lan rules that were not right, and his AP trying to talk to pool.ntp.org that he was blocking.



  • @johnpoz:

    Its is NOT his cable company router – its typical dhcp chatter.  I have seen the captures.

    All cable modems have a method for the ISP to get in and admin them. 99% of cable ISP's use a subnet in the 10.x.x.x  private block as does my past employer…   So please understand that this is the cable company's admin system showing up in his logs. Im am not guessing- trust me. Yes it is DHCP related but its handing the modems out addresses in the admin subnet.

    If one was to ping every address on that subnet from their cable modem they would see all the other customers on their node. But I didn't tell you that.

    As stated before more than once in this thread, use the steps that GruensFroeschli posted in the second post and your golden.


  • LAYER 8 Global Moderator

    No its not just handing out modems IP in the admin subnets, its normal dhcp chatter.

    Yes its the modems IP as well, you can see their config files they can boot from in the chatter.

    But most of it is just normal dhcp chatter.




  • @johnpoz:

    No its not just handing out modems IP in the admin subnets, its normal dhcp chatter.

    Yes its the modems IP as well, you can see their config files they can boot from in the chatter.

    But most of it is just normal dhcp chatter.

    3 days no sleep. Sorry what I meant was "Yes it is DHCP related but it is also handing the modems out addresses in the admin subnet."

    And yes it is coming from an ISP DHCP server. (sorry I called it a router)…

    In his logs "10.226.64.1 is the cable company's (CMTS / router / dhcp server / big overworked computer in the corner / whatever that is being used as a DHCP server on the ISP (cable co.) premises...

    If he was to ping and query hostnames every address on the subnet 10.226.64.0/20  (guessing at 20 as we used here when I was in the industry) he would get answers from about every type of modem that is docsis 1.1 compliant and up...   For admin thry are now 10.28.0.0/20 on my node here. (Dont remember what we started out with service area wide years ago when I was there.)

    For ease Ill say yes it also hands out the public IP's to the device past the modem (or to the gateway device if thats what your using) But it is coming from the ISP premises.

    I guess its possible some other ISP solution uses a similar method to do things but my guess that he's on a cable bridge solution is probably spot on.

    Guess I should ask...  dont ya think dhcp chatter, not related to the ISP would be a bad thing on a WAN port?

    Now Im going back to sleep.


  • LAYER 8 Global Moderator

    Yes I agree its ISP dhcp chatter, and yes I would agree non related isp dhcp chatter would be a bad thing ;)



  • Funny you should mention…  Guess what I had to go find at a clients office today....  Guess someones looking for a new job now.  Linksys wireless router plugged into the lan port running its DHCP server still...

    Bummer!      :o


Log in to reply