Results 1 to 6 of 6
  1. #1
    Newbie
    Join Date
    Oct 2018
    Posts
    9

    Default Application control not blocking port 53 that is not DNS

    This is a continuation of a different thread, but is a different problem. If I should have posted in the old thread, sorry!

    I am trying to get application control to block anything on port 53 that is not detected as DNS. It was doing that several weeks ago, but I left it alone for awhile. When I came back to it today, I noticed that it allowing traffic on port 53 that is not detected as DNS.

    Here is the report:

    i.imgur.com/of3TCM4.png

    For some reason the blocks aren't showing in the report, unless I export them:

    i.imgur.com/XkswFGQ.png


    Here is the rules (I am a home user, so they may be off - be gentle):

    i.imgur.com/gWZhEAf.png

    I figure in the rules I could have something like */DNS for the protochain, but I was trying to be explicit in my rules for this. I have also tried to create a rule that has the destination port 53 that is not application DNS instead of the protochain with the same results. Wondering what I might be doing wrong. Any help would be greatly appreciated!



    The original issue was attempting to block psiphon. The thread is here: forums.untangle.com/application-control/41173-blocking-psiphon.html I noticed that psiphon almost always seems to attempt to connect using port 53, which it may be encrypting. Someone else suggested redirecting all port 53 traffic to my internal DNS server, but I haven't been successful in finding a way to do that in Untangle.

    In the original issue, psiphon is only sometimes getting detected and tarpitted. What I have found is if port 53 is tarpitted during psiphon's connect attempt, it seems to fall back to port 80, which untangle is able to detected and tarpit. I am hoping to tarpit its attempts on port 53 and see if that make the attempts less successful.

  2. #2
    Untangle Junkie dmorris's Avatar
    Join Date
    Nov 2006
    Location
    San Carlos, CA
    Posts
    17,729

    Default

    Read the bold comments in docs that explain whats happening here.

    BTW, the first or the second rule will ALWAYS match for all applications including DNS.
    If A != B, then it is also true that for all X then X != A or X != B.

    You need something like *DNS* in one rule.
    Its entirely possible it still won't block as you're expecting, because of big bold comments in documentation here:
    https://wiki.untangle.com/index.php/..._Control#Rules
    Last edited by dmorris; 11-20-2018 at 07:25 PM.
    Attention: Support and help on the Untangle Forums is provided by volunteers and community members like yourself.
    If you need Untangle support please call or email support@untangle.com

  3. #3
    Master Untangler
    Join Date
    May 2010
    Location
    Texas, USA
    Posts
    690

    Default

    Quote Originally Posted by at5147 View Post
    The original issue was attempting to block psiphon. The thread is here: forums.untangle.com/application-control/41173-blocking-psiphon.html I noticed that psiphon almost always seems to attempt to connect using port 53, which it may be encrypting. Someone else suggested redirecting all port 53 traffic to my internal DNS server, but I haven't been successful in finding a way to do that in Untangle.
    That is super simple. Make a port forward that any DNS traffic that is outbound, and not from the Untangle IP, gets redirected to the Untangle IP. I'm pretty sure I have posted pics of my port forward rule on here before... But I would be happy to again tonight when I get home if it would help. It works very well, and also has a nice side effect of forcing IoT things to use my DNS without breaking them - even if their DNS is hard coded (I'm looking at you Google Home devices).

    Of course, if devices start using encrypted DNS then the party is over. Which I'm sure is coming any time now...

    Now if Untangle's own DNS service decides to forward along non-DNS traffic for some bizarre reason then the port forward wouldn't help. But I have never seen it do that - it seems to reject non-DNS traffic as expected.
    Last edited by JasonJoel; 11-21-2018 at 06:38 AM.
    Jim.Alles likes this.

  4. #4
    Untangle Junkie dmorris's Avatar
    Join Date
    Nov 2006
    Location
    San Carlos, CA
    Posts
    17,729

    Default

    Quote Originally Posted by JasonJoel View Post
    That is super simple. Make a port forward that any DNS traffic that is outbound, and not from the Untangle IP, gets redirected to the Untangle IP. I'm pretty sure I have posted pics of my port forward rule on here before... But I would be happy to again tonight when I get home if it would help. It works very well, and also has a nice side effect of forcing IoT things to use my DNS without breaking them - even if their DNS is hard coded (I'm looking at you Google Home devices).

    Of course, if devices start using encrypted DNS then the party is over. Which I'm sure is coming any time now...

    Now if Untangle's own DNS service decides to forward along non-DNS traffic for some bizarre reason then the port forward wouldn't help. But I have never seen it do that - it seems to reject non-DNS traffic as expected.
    Yes, this is a great idea.
    Just port forward any port 53 traffic destination interface = external to your local internal IP address.

    It will answer (and forward) all DNS. Anything else will just be ignored because its not DNS.
    JasonJoel likes this.
    Attention: Support and help on the Untangle Forums is provided by volunteers and community members like yourself.
    If you need Untangle support please call or email support@untangle.com

  5. #5
    Master Untangler
    Join Date
    May 2010
    Location
    Texas, USA
    Posts
    690

    Default

    Example port forward rule for this. The rule could be tweaked, but it works as-is so I haven't bothered streamlining/cleaning it up.

    I wanted to be 100% sure the port forward wouldn't affect traffic to/from the Untangle box itself, thus the extra 'is NOT' conditions.

    I have a similar rule for my IoT network that is on a different subnet/VLAN.

    Capture.PNG
    Last edited by JasonJoel; 11-21-2018 at 09:11 AM.
    Jim.Alles likes this.

  6. #6
    Newbie
    Join Date
    Oct 2018
    Posts
    9

    Default

    Wow! Thank you so much for that! I thought it might be a port forward rule, but I wasn't able to configure it properly. Thanks again!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

SEO by vBSEO 3.6.0 PL2