Http and https only
-
bump
-
"can a rule be setup for vlan10 members to look at 10.0.10.1 for DNS?"
You already have it - that first rule there says tcp/udp to 53 (dns) to the vlan10 address, I would assume if your vlan10 is 10.0.10.0/24 and you mention 10.0.10.1 for dns that is your vlan10 address on pfsense? Again have you verified that pfsense dns is listening on that port? Do simple dig to that address.. Does it work or not? Check with netstat if pfsense is listening on 53 on that address.
Your 2nd rule is pointless since your going to block everything with your last rule. Nor do I understand your udp http and https, nor do I understand your 8080, unless your trying to talk to proxy. If your talking to a proxy you don't need the 53 rule nor will you box ask what he has setup for dns if he is using a proxy normally. Proxy needs to be able to do the dns query.
You still can not be working on this, this was weeks ago.
-
"can a rule be setup for vlan10 members to look at 10.0.10.1 for DNS?"
You already have it - that first rule there says tcp/udp to 53 (dns) to the vlan10 address, I would assume if your vlan10 is 10.0.10.0/24 and you mention 10.0.10.1 for dns that is your vlan10 address on pfsense? Again have you verified that pfsense dns is listening on that port? Do simple dig to that address.. Does it work or not? Check with netstat if pfsense is listening on 53 on that address.
Your 2nd rule is pointless since your going to block everything with your last rule. Nor do I understand your udp http and https, nor do I understand your 8080, unless your trying to talk to proxy. If your talking to a proxy you don't need the 53 rule nor will you box ask what he has setup for dns if he is using a proxy normally. Proxy needs to be able to do the dns query.
You still can not be working on this, this was weeks ago.
vlan10 is there for testing, the last time i was working on it was when i made the thread, so yes, i am still working on this, but not very active. everything was working until i tried to create the rule for force the use of pfsense DNS servers.
8080- pfsense
80- internetas the rules are now, dns lookups dont work.
-
And again – have you verified pfsense is listening on 53 on that address? Do an actual QUERY!!
example
here is my pfsense box
[2.1-BETA1][johnpoz@pfsense.local.lan]/(8): sockstat -l | grep :53
root miniupnpd 82069 14 udp4 192.168.1.253:5351 :
nobody dnsmasq 55080 3 udp4 *:53 :
nobody dnsmasq 55080 4 tcp4 *:53 :
nobody dnsmasq 55080 5 udp6 *:53 :
nobody dnsmasq 55080 6 tcp6 *:53 :See dnsmasq listening on 53 on all IPs
here is a dig pfsense to that IP
[2.1-BETA1][johnpoz@pfsense.local.lan]/(9): dig @192.168.1.253 www.google.com; <<>> DiG 9.6.-ESV-R5-P1 <<>> @192.168.1.253 www.google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59056
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0;; QUESTION SECTION:
;www.google.com. IN A;; ANSWER SECTION:
www.google.com. 83 IN A 74.125.225.208
www.google.com. 83 IN A 74.125.225.211
www.google.com. 83 IN A 74.125.225.210
www.google.com. 83 IN A 74.125.225.209
www.google.com. 83 IN A 74.125.225.212;; Query time: 13 msec
;; SERVER: 192.168.1.253#53(192.168.1.253)
;; WHEN: Sat Mar 9 15:59:47 2013
;; MSG SIZE rcvd: 112Then finally from my windows box
C:\Windows\system32>dig @192.168.1.253 www.google.com
; <<>> DiG 9.9.2-P1 <<>> @192.168.1.253 www.google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42297
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0;; QUESTION SECTION:
;www.google.com. IN A;; ANSWER SECTION:
www.google.com. 45 IN A 74.125.225.209
www.google.com. 45 IN A 74.125.225.212
www.google.com. 45 IN A 74.125.225.208
www.google.com. 45 IN A 74.125.225.211
www.google.com. 45 IN A 74.125.225.210;; Query time: 2 msec
;; SERVER: 192.168.1.253#53(192.168.1.253)
;; WHEN: Sat Mar 09 16:00:25 2013
;; MSG SIZE rcvd: 112or if you don't have dig installed on your windows box or linux box on that vlan, then use nslookup. Set debug if you want!
C:\Windows\system32>nslookup
Default Server: pfsense.local.lan
Address: 192.168.1.253server 192.168.1.253
Default Server: pfsense.local.lan
Address: 192.168.1.253set debug
www.google.com.
Server: pfsense.local.lan
Address: 192.168.1.253–----------
Got answer:
HEADER:
opcode = QUERY, id = 7, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 5, authority records = 0, additional = 0QUESTIONS:
www.google.com, type = A, class = IN
ANSWERS:
-> www.google.com
internet address = 173.194.43.48
ttl = 15 (15 secs)
-> www.google.com
internet address = 173.194.43.52
ttl = 15 (15 secs)
-> www.google.com
internet address = 173.194.43.50
ttl = 15 (15 secs)
-> www.google.com
internet address = 173.194.43.49
ttl = 15 (15 secs)
-> www.google.com
internet address = 173.194.43.51
ttl = 15 (15 secs)
Non-authoritative answer:
Got answer:
HEADER:
opcode = QUERY, id = 8, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 0, additional = 0QUESTIONS:
www.google.com, type = AAAA, class = IN
ANSWERS:
-> www.google.com
AAAA IPv6 address = 2607:f8b0:4006:803::1014
ttl = 26 (26 secs)
Name: www.google.com
Addresses: 2607:f8b0:4006:803::1014
173.194.43.48
173.194.43.52
173.194.43.50
173.194.43.49
173.194.43.51Have you enabled logging on that rule that its passing traffic, have you sniffed on pfsense to verify the query gets there!
Its just amazing how many people want to run pfsense, and just don't have clue one to how to do even the most basic of troubleshooting. So you want to run vlans -- but you don't know how to verify traffic or that something is actually listening, etc.
btw - your 8080 rule is ANY not pfsense vlan10 address.
-
it is amazing how people assume just because you are running pfsense you are supposed to know everything about it.
dig @10.0.10.1 www.google.com
; <<>> DiG 9.8.3-P1 <<>> @10.0.10.1 www.google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40677
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0;; QUESTION SECTION:
;www.google.com. IN A;; ANSWER SECTION:
www.google.com. 50 IN A 74.125.225.180
www.google.com. 50 IN A 74.125.225.179
www.google.com. 50 IN A 74.125.225.176
www.google.com. 50 IN A 74.125.225.177
www.google.com. 50 IN A 74.125.225.178;; Query time: 10 msec
;; SERVER: 10.0.10.1#53(10.0.10.1)
;; WHEN: Sat Mar 9 16:12:34 2013
;; MSG SIZE rcvd: 112 -
And is that from your client or your pfsense box?
So since that is 9.8.3-p1 I have to ASSUME that is from your windows box or some other box on lan, I don't think pfsense is running that version. 2.1 sure isn't
Ok then there you go your RULE works! You can query pfsense for dns.. So that is NOT your problem.
Is that what your client is pointing to? Post your ipconfig /all
This has NOTHING to do with pfsense - this is basic common sense troubleshooting.. I would think if you understand enough to want to run a vlan, you would understand how to TEST basic services.
So either your NOT pointing to pfsense like you think you are, or your browser is using a proxy? But its sure not an issue with your computer not being able to query pfsense for dns. You sure your browser is not pointing to a proxy? Like running squid on pfsense?
-
i did that dig from my mac on vlan10.
the rules seemed to be ok until i added the extra rule to ignore any user entered DNS and force pfsense to intercept DNS lookups on port 53.
that is why i assumed it was an issue with dns. when i try to go to www.google.com it doesnt load.
i am going to try with a windows computer, if it works with a windows computer, i am going to throw this mac out the window.
-
Your MAC is prob not using 10.0.10.1 as its dns! I would bet on it! I recall some other thread, maybe not here where a mac was not using what he was handing out for dns. He had installed dnscrypt on it ;)
Simple enough to setup logging on your block rule, what gets blocked from your mac ;)
-
Your MAC is prob not using 10.0.10.1 as its dns! I would bet on it! I recall some other thread, maybe not here where a mac was not using what he was handing out for dns. He had installed dnscrypt on it ;)
Simple enough to setup logging on your block rule, what gets blocked from your mac ;)
:D
yeah that was me…i uninstalled that program that day.
btw, the problem started happening when i added that rule.
anyway, the good news is i dont have to throw my mac out the window...look at what my windows 8 laptop does...
C:\Users\admin>nslookup google.com
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 8.8.8.8DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to UnKnown timed-outi statically assigned 8.8.8.8, i want to mirror a user typing in their own DNS server.
the object is for pfsense to ignore a user entered DNS address and use the DNS servers i have set in pfsense.
-
Yeah so its working as designed!
So what is your problem - no shit your not going to be able to use the internet if you can not do dns ;)
-
Yeah so its working as designed!
So what is your problem - no shit your not going to be able to use the internet if you can not do dns ;)
maybe i suck at explaining things (very possible).
right now something is not working on vlan10 after i added the rule for pfsense to ignore other DNS servers.
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.
right now that isnt happening.
EDIT-
let me clarify (this could be where the issue is with me saying it isnt working), when the adapter is on obtain automatically, everything works fine. if the user edits their network settings to 8.8.8.8 or anything other than 10.0.10.1 (what dhcp hands out for dns), then it doesnt work. i am trying to still have it work for the users, but not with their user defined DNS server. i want pfsense to see that the user typed in 8.8.8.8 but deny that and force 208.67.222.222 and 208.67.220.220 (which is what i have set in pfsense).that might help clear up the issue i am having.
thanks.
-
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.
-
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?