Navigation

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

    Some wireless clients getting around opendns

    General pfSense Questions
    6
    18
    587
    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.
    • A
      adoucette last edited by

      I am trying to force my home network clients to use OpenDNS' DNS servers for purposes of internet content filtering. However, while this seems to work for the Windows computers on the network, the android phones and tablets can still browse to unwanted sites.

      I have followed the instructions here
      Pfsense 2.3.1 with OpenDNS (Web filtering)
      and here
      Redirecting all DNS Requests to pfSense
      The network topology has wired LAN clients and a wireless routers connected to the pfSense box by unmanaged switches. The wireless routers are set to be access points with the DHCP and DNS pointing to the pfSense box.

      What am I missing here, or are there additional instructions for pfSense settings or rules that I should add?

      Thank you,
      Ari

      1 Reply Last reply Reply Quote 0
      • KOM
        KOM last edited by

        If you followed the Redirecting DNS document and didn't make any mistakes, then it's impossible for them to use an alternate DNS while on your network.  A possible exception would be phones/tablets with a data plan.

        1 Reply Last reply Reply Quote 0
        • A
          adoucette last edited by

          The firewall rule is attached as a screenshot. It is the only NAT rule on the system.
          I have also attached DNS Forwarder and DNS Resolver settings, as those are mentioned in the above instructions.






          1 Reply Last reply Reply Quote 0
          • KOM
            KOM last edited by

            Looks good to me.  So, the problem is isolated to only devices that have mobile data plans?

            1 Reply Last reply Reply Quote 0
            • A
              adoucette last edited by

              @KOM:

              Looks good to me.  So, the problem is isolated to only devices that have mobile data plans?

              I agree that would be an obvious way to get around the pfSense DNS, and thank you for suggesting that, but I did ensure that was not the case. (Tablet has no mobile data, phone was in airplane mode with only wifi turned on. Both had browsers closed and then device rebooted to ensure no cached DNS was being used. There was no VPN etc enabled.)

              1 Reply Last reply Reply Quote 0
              • A
                adoucette last edited by

                OK, I think I have it. It looks like the problem is in the browser that was used on the android devices. It looks like "Puffin" browser uses its own DNS servers. See here: How to block internet access through puffin browser

                So, I can go ahead and block the IP addresses (CIDR) used by Puffin Web Browser:
                107.178.32.0/20
                45.33.128.0/20
                101.127.206.0/23
                101.127.208.0/23

                However, this raises the question for me as to whether other apps could simply circumvent this DNS filtering in the same way…
                I'm currently using OpenDNS to filter traffic, and using pfBlockerNG with these blocklists to try to filter out some malware.
                Is there a better way to go about filtering traffic for the kids on the home network?

                1 Reply Last reply Reply Quote 0
                • johnpoz
                  johnpoz LAYER 8 Global Moderator last edited by

                  If you don't want clients to use other dns, then block it.. And only allow them to talk to pfsense for dns which you set to use opendns… Or just redirect all dns traffic, etc.

                  I am more of a fan of block vs redirect for users, but redirecting can come in handy for devices that are hard coded to use some specific public dns like google, etc.

                  An intelligent man is sometimes forced to be drunk to spend time with his fools
                  If you get confused: Listen to the Music Play
                  Please don't Chat/PM me for help, unless mod related
                  SG-2440 2.4.5p1 | 4x SG-3100 2.4.4p3 | SG-4860 21.05.2

                  1 Reply Last reply Reply Quote 0
                  • KOM
                    KOM last edited by

                    Even if Puffin is using its own DNS, how does that let your devices go around the redirection?  Do you have your LAN rules in some weird order?

                    1 Reply Last reply Reply Quote 0
                    • Derelict
                      Derelict LAYER 8 Netgate last edited by

                      Another "Invert match" rule misbehaving?

                      I'd love to see the contents of /tmp/rules.debug

                      Chattanooga, Tennessee, USA
                      The pfSense Book is free of charge!
                      DO NOT set a source port in a port forward or firewall rule unless you KNOW you need it!
                      Do Not Chat For Help! NO_WAN_EGRESS(TM)

                      1 Reply Last reply Reply Quote 0
                      • johnpoz
                        johnpoz LAYER 8 Global Moderator last edited by

                        Yeah I see that is an invert.. But lets see the rules on lan… For all we know derelict is its below the any any rule ;)

                        An intelligent man is sometimes forced to be drunk to spend time with his fools
                        If you get confused: Listen to the Music Play
                        Please don't Chat/PM me for help, unless mod related
                        SG-2440 2.4.5p1 | 4x SG-3100 2.4.4p3 | SG-4860 21.05.2

                        1 Reply Last reply Reply Quote 0
                        • Grimson
                          Grimson Banned last edited by

                          If you use IPv6 you also have to remember that you can't redirect traffic with a port forward on IPv6, so you need a blocking rule there.

                          1 Reply Last reply Reply Quote 0
                          • Derelict
                            Derelict LAYER 8 Netgate last edited by

                            the LAN rules will be in rules.debug.

                            Chattanooga, Tennessee, USA
                            The pfSense Book is free of charge!
                            DO NOT set a source port in a port forward or firewall rule unless you KNOW you need it!
                            Do Not Chat For Help! NO_WAN_EGRESS(TM)

                            1 Reply Last reply Reply Quote 0
                            • johnpoz
                              johnpoz LAYER 8 Global Moderator last edited by

                              yup… I would think a simple screenshot of his lan rules would be easier for him than posting rules.debug ;)

                              An intelligent man is sometimes forced to be drunk to spend time with his fools
                              If you get confused: Listen to the Music Play
                              Please don't Chat/PM me for help, unless mod related
                              SG-2440 2.4.5p1 | 4x SG-3100 2.4.4p3 | SG-4860 21.05.2

                              1 Reply Last reply Reply Quote 0
                              • A
                                adoucette last edited by

                                Here is my rules.debug:

                                set limit table-entries 2000000
set optimization normal
set limit states 384000
set limit src-nodes 384000

#System aliases

loopback = "{ lo0 }"
WAN = "{ em0 }"
LAN = "{ em1 }"

#SSH Lockout Table
table <sshlockout> persist
table <webconfiguratorlockout> persist
#Snort tables
table <snort2c>
table <virusprot>
table <bogons> persist file "/etc/bogons"
table <negate_networks> 

# User Aliases 
table <pfb_spamhaus_drop> persist file "/var/db/aliastables/pfB_spamhaus_drop.txt"
pfB_spamhaus_drop = "<pfb_spamhaus_drop>"
table <pfb_spamhaus_edrop> persist file "/var/db/aliastables/pfB_spamhaus_edrop.txt"
pfB_spamhaus_edrop = "<pfb_spamhaus_edrop>"
table <pfb_ds_block> persist file "/var/db/aliastables/pfB_ds_block.txt"
pfB_ds_block = "<pfb_ds_block>"
table <pfb_feodo> persist file "/var/db/aliastables/pfB_feodo.txt"
pfB_feodo = "<pfb_feodo>"
table <pfb_sslbl> persist file "/var/db/aliastables/pfB_sslbl.txt"
pfB_sslbl = "<pfb_sslbl>"
table <pfb_zeus> persist file "/var/db/aliastables/pfB_zeus.txt"
pfB_zeus = "<pfb_zeus>"
table <pfb_bambenek> persist file "/var/db/aliastables/pfB_bambenek.txt"
pfB_bambenek = "<pfb_bambenek>"
table <pfblockerngsuppress> persist
pfBlockerNGSuppress = "<pfblockerngsuppress>"

# Gateways
GWWAN_DHCP = " route-to ( em0 72.209.222.1 ) "

set loginterface em1

set skip on pfsync0

scrub on $WAN all    fragment reassemble
scrub on $LAN all    fragment reassemble

no nat proto carp
no rdr proto carp
nat-anchor "natearly/*"
nat-anchor "natrules/*"

# Outbound NAT rules (automatic)

# Subnets to NAT 
tonatsubnets	= "{ 127.0.0.0/8 192.168.10.0/24 }"
nat on $WAN  from $tonatsubnets to any port 500 -> 72.209.222.27/32  static-port
nat on $WAN  from $tonatsubnets to any -> 72.209.222.27/32 port 1024:65535  

# Load balancing anchor
rdr-anchor "relayd/*"
# TFTP proxy
rdr-anchor "tftp-proxy/*"
# NAT Inbound Redirects
rdr on em1 proto { tcp udp } from any to !192.168.10.1 port 53 -> 127.0.0.1
# UPnPd rdr anchor
rdr-anchor "miniupnpd"

anchor "relayd/*"
anchor "openvpn/*"
anchor "ipsec/*"
# Allow IPv6 on loopback
pass in  quick on $loopback inet6 all tracker 1000000001 label "pass IPv6 loopback"
pass out  quick on $loopback inet6 all tracker 1000000002 label "pass IPv6 loopback"
# Block all IPv6
block in log quick inet6 all tracker 1000000003 label "Block all IPv6"
block out log quick inet6 all tracker 1000000004 label "Block all IPv6"
# block IPv4 link-local. Per RFC 3927, link local "MUST NOT" be forwarded by a routing device,
# and clients "MUST NOT" send such packets to a router. FreeBSD won't route 169.254./16, but
# route-to can override that, causing problems such as in redmine #2073
block in log quick from 169.254.0.0/16 to any tracker 1000000101 label "Block IPv4 link-local"
block in log quick from any to 169.254.0.0/16 tracker 1000000102 label "Block IPv4 link-local"
#---------------------------------------------------------------------------
# default deny rules
#---------------------------------------------------------------------------
block in log inet all tracker 1000000103 label "Default deny rule IPv4"
block out log inet all tracker 1000000104 label "Default deny rule IPv4"
block in log inet6 all tracker 1000000105 label "Default deny rule IPv6"
block out log inet6 all tracker 1000000106 label "Default deny rule IPv6"
# We use the mighty pf, we cannot be fooled.
block log quick inet proto { tcp, udp } from any port = 0 to any tracker 1000000107 label "Block traffic from port 0"
block log quick inet proto { tcp, udp } from any to any port = 0 tracker 1000000108 label "Block traffic to port 0"

# Snort package
block log quick from <snort2c> to any tracker 1000000109 label "Block snort2c hosts"
block log quick from any to <snort2c> tracker 1000000110 label "Block snort2c hosts"

# SSH lockout
block in log quick proto tcp from <sshlockout> to (self) port 28354 tracker 1000000301 label "sshlockout"

# webConfigurator lockout
block in log quick proto tcp from <webconfiguratorlockout> to (self) port 28355 tracker 1000000351 label "webConfiguratorlockout"
block in log quick from <virusprot> to any tracker 1000000400 label "virusprot overload table"
# block bogon networks (IPv4)
# http://www.cymru.com/Documents/bogon-bn-nonagg.txt
block in log quick on $WAN from <bogons> to any tracker 11000 label "block bogon IPv4 networks from WAN"
antispoof log for $WAN tracker 1000001570
# block anything from private networks on interfaces with the option set
block in log quick on $WAN from 10.0.0.0/8 to any tracker 12000 label "Block private networks from WAN block 10/8"
block in log quick on $WAN from 127.0.0.0/8 to any tracker 12000 label "Block private networks from WAN block 127/8"
block in log quick on $WAN from 172.16.0.0/12 to any tracker 12000 label "Block private networks from WAN block 172.16/12"
block in log quick on $WAN from 192.168.0.0/16 to any tracker 12000 label "Block private networks from WAN block 192.168/16"
block in log quick on $WAN from fc00::/7 to any tracker 12000 label "Block ULA networks from WAN block fc00::/7"
# allow our DHCP client out to the WAN
pass in  on $WAN proto udp from any port = 67 to any port = 68 tracker 1000001591 label "allow dhcp client out WAN"
pass out  on $WAN proto udp from any port = 68 to any port = 67 tracker 1000001592 label "allow dhcp client out WAN"
# Not installing DHCP server firewall rules for WAN which is configured for DHCP.
antispoof log for $LAN tracker 1000002620
# allow access to DHCP server on LAN
pass in  quick on $LAN proto udp from any port = 68 to 255.255.255.255 port = 67 tracker 1000002641 label "allow access to DHCP server"
pass in  quick on $LAN proto udp from any port = 68 to 192.168.10.1 port = 67 tracker 1000002642 label "allow access to DHCP server"
pass out  quick on $LAN proto udp from 192.168.10.1 port = 67 to any port = 68 tracker 1000002643 label "allow access to DHCP server"
# allow access to DHCPv6 server on LAN
# We need inet6 icmp for stateless autoconfig and dhcpv6
pass  quick on $LAN inet6 proto udp from fe80::/10 to fe80::/10 port = 546 tracker 1000002651 label "allow access to DHCPv6 server"
pass  quick on $LAN inet6 proto udp from fe80::/10 to ff02::/16 port = 546 tracker 1000002652 label "allow access to DHCPv6 server"
pass  quick on $LAN inet6 proto udp from fe80::/10 to ff02::/16 port = 547 tracker 1000002653 label "allow access to DHCPv6 server"
pass  quick on $LAN inet6 proto udp from ff02::/16 to fe80::/10 port = 547 tracker 1000002654 label "allow access to DHCPv6 server"

# loopback
pass in  on $loopback inet all tracker 1000002661 label "pass IPv4 loopback"
pass out  on $loopback inet all tracker 1000002662 label "pass IPv4 loopback"
# let out anything from the firewall host itself and decrypted IPsec traffic
pass out  inet all keep state allow-opts tracker 1000002663 label "let out anything IPv4 from firewall host itself"

pass out  route-to ( em0 72.209.222.1 ) from 72.209.222.27 to !72.209.222.0/22 tracker 1000002761 keep state allow-opts label "let out anything from firewall host itself"
# make sure the user cannot lock himself out of the webConfigurator or SSH
pass in  quick on em1 proto tcp from any to (em1) port { 28355 28354 } tracker 10000 keep state label "anti-lockout rule"

# User-defined rules follow

anchor "userrules/*"
block  in log  quick  on $WAN reply-to ( em0 72.209.222.1 ) inet from $pfB_spamhaus_drop to any tracker 1770009076  label "USER_RULE: pfB_spamhaus_drop auto rule"
block  in log  quick  on $WAN reply-to ( em0 72.209.222.1 ) inet from $pfB_spamhaus_edrop to any tracker 1770009177  label "USER_RULE: pfB_spamhaus_edrop auto rule"
block  in log  quick  on $WAN reply-to ( em0 72.209.222.1 ) inet from $pfB_ds_block to any tracker 1770008511  label "USER_RULE: pfB_ds_block auto rule"
block  in log  quick  on $WAN reply-to ( em0 72.209.222.1 ) inet from $pfB_feodo to any tracker 1770008203  label "USER_RULE: pfB_feodo auto rule"
block  in log  quick  on $WAN reply-to ( em0 72.209.222.1 ) inet from $pfB_sslbl to any tracker 1770008222  label "USER_RULE: pfB_sslbl auto rule"
block  in log  quick  on $WAN reply-to ( em0 72.209.222.1 ) inet from $pfB_zeus to any tracker 1770008133  label "USER_RULE: pfB_zeus auto rule"
block  in log  quick  on $WAN reply-to ( em0 72.209.222.1 ) inet from $pfB_bambenek to any tracker 1770008499  label "USER_RULE: pfB_bambenek auto rule"
block return  in log  quick  on $LAN inet from any to $pfB_spamhaus_drop tracker 1770009700  label "USER_RULE: pfB_spamhaus_drop auto rule"
block return  in log  quick  on $LAN inet from any to $pfB_spamhaus_edrop tracker 1770009801  label "USER_RULE: pfB_spamhaus_edrop auto rule"
block return  in log  quick  on $LAN inet from any to $pfB_ds_block tracker 1770009135  label "USER_RULE: pfB_ds_block auto rule"
block return  in log  quick  on $LAN inet from any to $pfB_feodo tracker 1770008827  label "USER_RULE: pfB_feodo auto rule"
block return  in log  quick  on $LAN inet from any to $pfB_sslbl tracker 1770008846  label "USER_RULE: pfB_sslbl auto rule"
block return  in log  quick  on $LAN inet from any to $pfB_zeus tracker 1770008757  label "USER_RULE: pfB_zeus auto rule"
block return  in log  quick  on $LAN inet from any to $pfB_bambenek tracker 1770009123  label "USER_RULE: pfB_bambenek auto rule"
pass  in  quick  on $LAN inet proto { tcp udp }  from any to 127.0.0.1 port 53 tracker 1519738712 keep state  label "USER_RULE: NAT Redirect DNS"
pass  in  quick  on $LAN inet from 192.168.10.0/24 to any tracker 0100000101 keep state  label "USER_RULE: Default allow LAN to any rule"
# at the break! label "USER_RULE: Default allow LAN IPv6 to any rule"

# VPN Rules

anchor "tftp-proxy/*"</bogons></virusprot></webconfiguratorlockout></sshlockout></snort2c></snort2c></pfblockerngsuppress></pfblockerngsuppress></pfb_bambenek></pfb_bambenek></pfb_zeus></pfb_zeus></pfb_sslbl></pfb_sslbl></pfb_feodo></pfb_feodo></pfb_ds_block></pfb_ds_block></pfb_spamhaus_edrop></pfb_spamhaus_edrop></pfb_spamhaus_drop></pfb_spamhaus_drop></negate_networks></bogons></virusprot></snort2c></webconfiguratorlockout></sshlockout>

                                And I have attached screenshots of the lan rules.


                                1 Reply Last reply Reply Quote 0
                                • Derelict
                                  Derelict LAYER 8 Netgate last edited by

                                  That looks like it should work.

                                  What is the DNS configuration of the DNS resolver or forwarder that you are redirecting to?

                                  You could try adding a reject rule after this:

                                  pass  in  quick  on $LAN inet proto { tcp udp }  from any to 127.0.0.1 port 53 tracker 1519738712 keep state  label "USER_RULE: NAT Redirect DNS"

                                  reject TCP/UDP from any to any port 53.

                                  Chattanooga, Tennessee, USA
                                  The pfSense Book is free of charge!
                                  DO NOT set a source port in a port forward or firewall rule unless you KNOW you need it!
                                  Do Not Chat For Help! NO_WAN_EGRESS(TM)

                                  1 Reply Last reply Reply Quote 0
                                  • A
                                    adoucette last edited by

                                    @Derelict:

                                    reject TCP/UDP from any to any port 53

                                    Unfortunately, that rule just stopped the other web browsers from working at all. (I put it after the DNS redirect rule)

                                    1 Reply Last reply Reply Quote 0
                                    • jahonix
                                      jahonix last edited by

                                      Your "allow DNS" rule never got hit by any traffic (0/ 0 B). I'd use Lan address (or even any) as destination.

                                      1 Reply Last reply Reply Quote 0
                                      • Derelict
                                        Derelict LAYER 8 Netgate last edited by

                                        @adoucette:

                                        @Derelict:

                                        reject TCP/UDP from any to any port 53

                                        Unfortunately, that rule just stopped the other web browsers from working at all. (I put it after the DNS redirect rule)

                                        OK then add a pass rule between those two rules that passes TCP/UDP from any to LAN address port 53.

                                        Damn Invert match rules suck. Just say no.

                                        Chattanooga, Tennessee, USA
                                        The pfSense Book is free of charge!
                                        DO NOT set a source port in a port forward or firewall rule unless you KNOW you need it!
                                        Do Not Chat For Help! NO_WAN_EGRESS(TM)

                                        1 Reply Last reply Reply Quote 0
                                        • First post
                                          Last post

                                        Products

                                        • Platform Overview
                                        • TNSR
                                        • pfSense
                                        • Appliances

                                        Services

                                        • Training
                                        • Professional Services

                                        Support

                                        • Subscription Plans
                                        • Contact Support
                                        • Product Lifecycle
                                        • Documentation

                                        News

                                        • Media Coverage
                                        • Press
                                        • Events

                                        Resources

                                        • Blog
                                        • FAQ
                                        • Find a Partner
                                        • Resource Library
                                        • Security Information

                                        Company

                                        • About Us
                                        • Careers
                                        • Partners
                                        • Contact Us
                                        • Legal
                                        Our Mission

                                        We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                                        Subscribe to our Newsletter

                                        Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                                        © 2021 Rubicon Communications, LLC | Privacy Policy