Http and https only
-
if a user types in 8.8.8.8 i still want them to be able to lookup websites, but not by using 8.8.8.8, instead, if should force the DNS servers i have set in pfsense.
Sorry it doesn't work like that! If a user doesn't ask pfsense for dns, it can not intercept the traffic for 8.8.8.8 and send its own answer - there is NO way to do what your asking.
You have it setup correctly, and again you don't need the extra 53 block rule. Your default block does that, your just allowing them to talk to pfsense on 53.
So if they want to ask googledns, it wont work!! They will have to ask pfsense for dns or not get dns.
There is NO way to intercept every DNS query sent to any IP address, and send an answer. With your rules they have a choice, use pfsense for dns, or don't get dns!
so you have
ask pfsense IP for dns - get answer from where pfsense forwards dns.
don't ask pfsense IP for dns - NO Answer.Unless of course they art talking to a dns server outside that is listening on ports 80, 443 or 8080 since your rules allow traffic out to anything on those ports. So if I asked a 8.8.8.8 a dns query on port 80, and it was LISTENING on 80 for dns then I could still get an answer. But since its not listening on 80 or 443 or 8080 for dns, then no it wouldn't work. But someone could run their own dns on one of the ports and work that way.
Or since 8080 is a common proxy port, I could set my browser to use some proxy outside vlan10 and have it do its own dns and send me back the websites, etc.
ok, i understand.
however, my old linksys router flashed with dd-wrt could do this.
i could enter in 1.2.3.4 for DNS and it would intercept/hijack that and use the server i had set in the admin panel of dd-wrt, which were opendns addresses.
if the user entered in 8.8.8.8 and went to welcome.opendns.com it displayed the "welcome to opendns page" even though they typed in the google dns server.
the rule in place now is better than nothing, thank you for sticking around to help.
-
"however, my old linksys router flashed with dd-wrt could do this."
NO IT DIDN'T!
I have used and played with dd-wrt for many years on many didn't routers - sorry it didn't do that! Not sure what you thought was happening. But I assure you dd-wrt did not intercept dns traffic for IP address a.b.c.d and then answer that query with an answer from some other dns server.
For that to happen your saying the router would spoof IP addresses of any query done to port 53.. And return answer to client from said spoofed address a.b.c.d with said dns query response. Sorry NO – show me the setting in dd-wrt that did this.
Where you maybe running a transparent proxy??
-
"however, my old linksys router flashed with dd-wrt could do this."
NO IT DIDN'T!
I have used and played with dd-wrt for many years on many didn't routers - sorry it didn't do that! Not sure what you thought was happening. But I assure you dd-wrt did not intercept dns traffic for IP address a.b.c.d and then answer that query with an answer from some other dns server.
For that to happen your saying the router was spoofing IP addresses of any query done to port 53.. Sorry NO – show me the setting in dd-wrt that did this.
yes it did.
i statically typed in 1.2.3.4 and opendns was forced.
edit- here is what i had to confgure in the router, first.
http://www.dd-wrt.com/wiki/index.php/OpenDNS#Intercept_DNS_Port
You can prevent users from using their own DNS servers (and hence get around content filtering) by intercepting DNS queries and forcing them to use the DNS servers you specify.
-
NO IT DIDN'T!! FACT!!!
You might have thought that was happening - but SORRY NO!! It doesn't work that way! PERIOD!
Think about it for 2 seconds – what process was watching traffic for dns queries?? There is nothing listening on 1.2.3.4 on your router, what magic process do you think was intercepting traffic for port 53 to IP address 1.2.3.4, and then returning traffic to your box saying it came from 1.2.3.4 with said answer??
-
NO IT DIDN'T!! FACT!!!
You might have thought that was happening - but SORRY NO!! It doesn't work that way! PERIOD!
hmm, ok.
read my edit.
-
Well WTF.. Slap my ass and call me sally ;)
So they are doing a dnat on the port. That is iptables, so you might be able to do the same thing with pf using rdr and nat.. So my BAD, you are right dd-wrt was doing it. In all my years playing with it, never thought of doing that - but its not part of the gui, you have to directly manipulate the iptable rules
iptables -t nat -A PREROUTING -i br0 -p udp --dport 53 -j DNAT --to $(nvram get lan_ipaddr) iptables -t nat -A PREROUTING -i br0 -p tcp --dport 53 -j DNAT --to $(nvram get lan_ipaddr)
Learn something new everyday - thanks! I would never think to do such a thing. I don't understand the point? If you don't want your clients using other dns, then block it and only allow use of your dns. Redirecting to your dns - why? That is underhanded and makes the setup more complex.
If you want to do that, I would suggest you create a new thread under firewall or nat sections asking about dns (port) interception and redirection..
-
Well WTF.. Slap my ass and call me sally ;)
So they are doing a dnat on the port. That is iptables, so you might be able to do the same thing with pf using rdr and nat.. So my BAD, you are right dd-wrt was doing it. In all my years playing with it, never thought of doing that - but its not part of the gui, you have to directly manipulate the iptable rules
iptables -t nat -A PREROUTING -i br0 -p udp --dport 53 -j DNAT --to $(nvram get lan_ipaddr) iptables -t nat -A PREROUTING -i br0 -p tcp --dport 53 -j DNAT --to $(nvram get lan_ipaddr)
Learn something new everyday - thanks! I would never think to do such a thing. I don't understand the point? If you don't want your clients using other dns, then block it and only allow use of your dns. Redirecting to your dns - why? That is underhanded and makes the setup more complex.
If you want to do that, I would suggest you create a new thread asking about dns interception and redirection..
thank you for coming back and admitting that you overlooked something.
the reason i would want to do this would be to force DNS servers. meaning, if a user comes in with their own device, realizes their lookups were being filtered by openDNS and tried setting their device to something else, this rule would have ignored their DNS entry and forced openDNS.
the way the current rule is setup, it would ignore the DNS server they changed it to and the lookups wouldn't work. that's fine, better than nothing, but that was one of the reasons i kept saying the rule wasnt working (and that was MY fault for not understanding exactly what it was doing).
you did mention something about not needing one of the rules. i am not on site now and i dont want to mess with anything while i am not there, so i will take a look at the rules and eliminate the one you said was not needed.
thanks.
-
Well would be stupid not to admit I was mistaken ;) The rule is right there how to do it on dd-wrt.. I might jump to conclusions now and then - that happens when you don't think things through.. I was thinking what dnsmasq does, and it sure doesn't do what you were describing. But there are multiple ways to skin the cat.
So if someone comes in with their own device, wouldn't they be getting IP from dhcp? Or wouldn't you be giving them an IP to use, mask, dns, etc.?
If they tried to circumvent by putting in there OWN dns - they would be blocked! This is makes it clear and upfront security - interception of someones traffic and redirecting it elsewhere is underhanded an pretty much a man in the middle sort of attack. I personally would not go down that road in securing your network.
If you only want to allow opendns, then limit it to that – don't be sneaky about it ;)
But now it makes more sense to why we were disconnected - talking about different things. Your rules were working as written ;) That rule is not a redirect rule..
as to your rules - I would fix up the upd on 80 and 443, this is not required. I would remove the explicit block of 53 after your allow to your vlan10 IP, since its redundant of the last rule that says hey if you didn't get allowed already I don't care where your going - your blocked! port 53 would be blocked by that rule.
If you have people bringing in their own devices, and don't want them using non opendns dns - I sure wouldn't allow them to use 8080 to anything. This is a common proxy port, if you say pfsense is listening on it. I would prob lock that down a bit to say only from known IPs on that vlan10 (admin boxes) Why would users need to hit the pfsense gui?
-
Well would be stupid not to admit I was mistaken The rule is right there how to do it on dd-wrt.. I might jump to conclusions now and then - that happens when you don't think things through..
i have been on other forums where users start making excuses or dont come back. glad to see that you are not that type of user.
users get DNS ip from dhcp server running on the vlan10 interface, no issues there. they get assigned 10.0.10.1 which is using opendns, that works fine, no issues there.
as far as intercepting, yeah, you are right, it is a bit sneaky (if they did try to enter in their own DNS and have an intercept occur).
i dont mind forcing opendns and NOT hiding it, but i dont want the users having a public IP as a dns entry, i want to keep everything on the private side (192, 10, 172, etc…). anyway, that would be a different thread, as you recommended in a previous reply. i will have to look into that to see if i want to continue with it.
for the 80 and 443, i wanted to force this interface to only use those ports (and 53 for dns). 8080 was there just for me to be able to get to pfsense when i was on that vlan for configuring/testing. once everything is working, i can delete that rule, it isnt needed.
thanks.
-
I understand the reason for the 80/443 rules - those are fine and normal type rules other than your also allowing UDP? http and https do not use UDP.. So that is pointless in the rule, and just allows traffic that you might not want ;)
As to making mistakes, we all do - its human. My fault was jumping to a conclusion that it doesn't do it before doing my own research, I had never come across such a feature before - used it for man years. My bad on that, and thanks for pointing it out to me - like I said you learn something every day.
I was clearly mistaken is my wording that it can't be done or doesn't do it. Should prob not have used the Cap Letters in my proclamation ;) Now in my defense, dnsmasq doesn't do it.. But that is of little matter in the big picture.
Might be a feature some people might get use out of such a feature - can't hurt to ask for it, etc. But clearly point out what your wanting is an intercept of ANY traffic dest to port 53 tcp/upd and want to redirect/nat that to your own local IP, or some other server IP, etc.
That's the part that I didn't catch til now - the NAT part, even if you intercept the traffic and send it somewhere else. It has to be natted to return that traffic back to the client. If I send a query to 1.2.3.4 and I get a answer back from 4.2.3.1 its not going to work - if it does that kind of a security issue ;) So that answer has to look like it came from 1.2.3.4, ie natted.
-
I understand the reason for the 80/443 rules - those are fine and normal type rules other than your also allowing UDP? http and https do use UDP.. So that is pointless in the rule, and just allows traffic that you might not want ;)
sorry, that is not the latest screen shot, i didn't upload a new one after i made some other changes (my fault, i should have).
thanks.
-
You can transparently redirect DNS traffic with port forwards. It's a whole lot cleaner to never do such things though.