Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Android App, to WAN being blocked..

    Scheduled Pinned Locked Moved Firewalling
    5 Posts 2 Posters 355 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • D
      diyhouse
      last edited by diyhouse

      when I use my android app to access an external resource, I get the following logs created.
      pfsenseLog.png

      I have tried using the facility to add rules,.. But I am not sure if I need to add a local LAN rule or WAN rule,..
      I believe I need to add a WAN rule, in combination with a NAT rule,.. but I am not quite sure how to config, as getting either wrong will and has been causing the app to fail to connect. To add to the complexity,.. the Android devices IP address can change when it attaches via to the local network.
      Can anyone offer me some advice on how I should start and how I need to configure my router.
      Many tx in advance..

      Many tx

      1 Reply Last reply Reply Quote 0
      • bmeeksB
        bmeeks
        last edited by bmeeks

        You appear to be running the Snort package in blocking mode as evidenced by the blocking from the snort2c pf table entry.

        You will need to look under the ALERTS and BLOCKS tabs in Snort, find the local IP of your Android device, and then determine what Snort rules are getting triggered and thus creating the block. Your Snort ruleset likely needs tuning as it appears to be too aggressive. There are many of the Snort rules that should never be enabled in many home networks.

        Snort blocks by placing IP addresses in a pre-defined pf packet engine table called snort2c. pfSense itself creates a special hidden rule high up in the rule set that blocks all IP addresses contained in the snort2c table. Your posted log snippet is showing the results of those actions.

        Find which rule is triggering for your Android device (by looking for the device's IP in the list on the BLOCKS tab; note what rule was responsible for the block; investigate to determine if the rule is a false positive; and if so, consider either suppressing that alert or disabling the particular rule. Disabling a rule that is giving a lot of false positives is preferable to suppressing it as disabling it removes it from the analysis engine and thus saves CPU cycles.

        D 1 Reply Last reply Reply Quote 0
        • D
          diyhouse @bmeeks
          last edited by

          @bmeeks Many tx for your replay,.. well went hunting snort things,...
          I tried 'remove from blocked table' and 'Rule is forced to a disable state... '
          none of these seemed to work... tried adding the ip address of the destination,.. to 'pass list',... and fingers crossed,. this seems to work,.. as the traffic and communication seems to work.

          So many thanks for pointing the obvious out to me,.. and getting me on the right trail..
          rgds MK

          bmeeksB 1 Reply Last reply Reply Quote 0
          • bmeeksB
            bmeeks @diyhouse
            last edited by

            @diyhouse said in Android App, to WAN being blocked..:

            @bmeeks Many tx for your replay,.. well went hunting snort things,...
            I tried 'remove from blocked table' and 'Rule is forced to a disable state... '
            none of these seemed to work... tried adding the ip address of the destination,.. to 'pass list',... and fingers crossed,. this seems to work,.. as the traffic and communication seems to work.

            So many thanks for pointing the obvious out to me,.. and getting me on the right trail..
            rgds MK

            When you disable a rule and reload the Snort ruleset, that will not remove any previously inserted blocks. You would still have to manually clear the BLOCKS tab entries (or at least all entries matching your Android device).

            It may be the case that multiple rules are triggering, so disabling one rule does not necessarily catch them all. The HTTP_INSPECT rules are particularly prone to false positives as they can be easily tripped up by all the "stuff" websites try these days to get around ad blockers and such.

            D 1 Reply Last reply Reply Quote 0
            • D
              diyhouse @bmeeks
              last edited by

              @bmeeks, yes I was wondering how that worked,.. and considered I may need to remove 'current block list',... but was nervous to try something that may break system.

              But I appreciate your pointers,.. and insight as to what is going on,.. again many tx for your replies.
              @diyhouse

              1 Reply Last reply Reply Quote 0
              • First post
                Last post
              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.