Cannot resolve Front End firewall hostname
-
My test network is setup like this:
Internal LAN -> Backend FW -> DMZ -> Frontend FW -> The Internet
I decided just sticking with DNS Forwarder so any client on the Internal LAN network uses the Backend FW as theird DNS server.
When doing an nslookup from a client in the Internal LAN, I can resolve the hostname of the Backend FW just fine. The problem is that I can't resolve the hostname of the Frontend FW.
If I change the server to use in that nslookup session to the IP address of the Frontend FW, then naturally it can resolve just fine.
Access to the Internet from the client works just fine. The forwarding seems to work just fine from the client all the way to the Internet but for some reason it can't resolve the hostname of the Frontend FW.
What do you guys think is the problem?
-
Well where is the nameserver that is authoritative for that firewalls fqdn? Where does the backend forward too. Are they both in the same domain, so it believes it authoritative for your domain. Lets clall it befw.yourdomain.tld and fefw.yourdomain.tld or is fe in a different domain?
-
Well where is the nameserver that is authoritative for that firewalls fqdn? Where does the backend forward too. Are they both in the same domain, so it believes it authoritative for your domain. Lets clall it befw.yourdomain.tld and fefw.yourdomain.tld or is fe in a different domain?
They are definitely in the same domain: fefw.yourdomain.tld and befw.yourdomain.tld. The backend forwards to the gateway of its WAN side and that is the LAN side IP address of the frontend.
When pfsense is set to use dnsmasq (dns forwarder), it does not a particular firewall rule to allow traffic to be accepted by itself, does it? I mean, forwarding works just fine.
-
and what does the frontend do? Seems pretty simple to just query it - does it know its own name?
C:>dig @192.168.1.253 pfsense.local.lan
; <<>> DiG 9.10-P2 <<>> @192.168.1.253 pfsense.local.lan
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8830
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;pfsense.local.lan. IN A;; ANSWER SECTION:
pfsense.local.lan. 3600 IN A 192.168.1.253;; Query time: 4 msec
;; SERVER: 192.168.1.253#53(192.168.1.253)
;; WHEN: Thu Feb 05 22:50:41 Central Standard Time 2015
;; MSG SIZE rcvd: 62So query the front and for its name??
-
This may sound obvious, but have you tried entering an A record for your frontend firewall on the DNS service running on your choke (backend) firewall?
-
and what does the frontend do? Seems pretty simple to just query it - does it know its own name?
C:>dig @192.168.1.253 pfsense.local.lan
; <<>> DiG 9.10-P2 <<>> @192.168.1.253 pfsense.local.lan
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8830
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;pfsense.local.lan. IN A
;; ANSWER SECTION:
pfsense.local.lan. 3600 IN A 192.168.1.253
;; Query time: 4 msec
;; SERVER: 192.168.1.253#53(192.168.1.253)
;; WHEN: Thu Feb 05 22:50:41 Central Standard Time 2015
;; MSG SIZE rcvd: 62So query the front and for its name??
It does know its name. My servers in the DMZ (LAN side of frontend) can query the frontend just fine. Heck when you do a Diagnostics -> DNS Lookup in the backend firewall, it can even resolve the hostname of the frontend firewall.
This may sound obvious, but have you tried entering an A record for your frontend firewall on the DNS service running on your choke (backend) firewall?
Well, that will definitely work. But my goal here is not to do that because my understanding is that if a client on the LAN side of the choke firewall queries for the hostname of the frontend, the choke DNS server will try to look that entry in its local database/cache first and if it doesn't find it will forward that query of the frontend. Now the frontend definitely has that entry in its local database/cache and should return an answer back to the choke firewall and ultimately to the end client. Does that make sense?
-
But your problem could be that the backend is in yourdomain.tld and sees no record for frontend.yourdomain.tld so never forwards it. As you stated they are in the same domain.
-
What Johnpoz said.
If both your firewalls are nameservers for the same domain, then the choke will never forward the request onto the other firewall since the choke will consider itself to be the SOA for that domain. Just add the entry for the outside firewall to your choke and you're there.
-
Ahh, got it! So the only requests that the backend will forward are those outside of its domain since it is the SOA for the domain, correct?
-
Yes
-
Now one of the networks behind the choke firewall has a domain controller in place which of course in itself is a DNS server. It is set to forward DNS requests to the choke firewall also. From a client in that same domain, it cannot resolve both be and fe hostnames and I'm assuming it's because of the same reason you guys stated.
The other networks behind the choke are only in a workgroup and they use the choke as their preferred DNS and DHCP servers and so their hostnames get registered in the cache of the choke.
Now how do I make the computers connected to the domain controller resolve the computers in the other workgroups? Should I manually add them as individual A records in the internal domain DNS server? That would be cumbersome if there are several other workgroup computers. Is there any other way?
-
let me guess this AD dns is the same domain name?
This seems really flawed.. If your going to have authoritative domain nameserver. All clients need to query this, or the nameserver they query should know to ask that nameserver for that domain. Conditional forwarder, ns record, something.
You should never have 3 different nameserver that don't contain the same data think they are authoritative for the same domain.
why don't you just create other domains or subdomains for these different groups of devices. Or just leverage 1 nameserver, say your AD dns to maintain all records. You can setup AD dns to allow for registration of clients that are not members of the domain for dynamic clients no matter where they get dhcp from. Anything else that is static could have A records created in your ad nameserver.
I would suggest rethink your nameservices. More than happy if you draw it out so we can get the big picture of how your attempting to do it.
-
let me guess this AD dns is the same domain name?
This seems really flawed.. If your going to have authoritative domain nameserver. All clients need to query this, or the nameserver they query should know to ask that nameserver for that domain. Conditional forwarder, ns record, something.
You should never have 3 different nameserver that don't contain the same data think they are authoritative for the same domain.
why don't you just create other domains or subdomains for these different groups of devices. Or just leverage 1 nameserver, say your AD dns to maintain all records. You can setup AD dns to allow for registration of clients that are not members of the domain for dynamic clients no matter where they get dhcp from. Anything else that is static could have A records created in your ad nameserver.
I would suggest rethink your nameservices. More than happy if you draw it out so we can get the big picture of how your attempting to do it.
That's what I thought. I'm just looking for a way on how to integrate everything so that everything resolves properly with each other automatically. Leveraging the AD DNS seems to be a very good idea but I'm not sure where to start. Here's a quick maps view of my test network in VMWare ESX:
https://www.dropbox.com/s/9sybazk7sesg5br/Capture.JPG?dl=0
Basically, the production, test laboratory, and guest lan's are separated by VLAN's and go through the trunk connected to the backend fw. Everything else seems to be self-explanatory.
Prod LAN has the AD DNS and all clients in that LAN are pointed to the AD DNS as their preferred DNS server. The AD DNS is setup to forward to the backend fw DNS.
The clients in the test laboratory and guest LAN's are pointed to the backend fw DNS as their preferred DNS server.
The backend fw is setup to forward to the frontend fw.
The client in the DMZ network (EDGE) is pointed to the frontend fw DNS as its preferred DNS server.
The frontend fw is setup to forward to the Google DNS servers.
What would be the best way to leverage just one internal DNS server?
-
"What would be the best way to leverage just one internal DNS server?"
Point your clients to it, create whatever records you wan in it.. Allow for dynamic registration for devices that support that. Now sure what your not understanding? You don't know how to create a A record in MS dns? You don't know how to allow registration from non ad members?
Your only thing is stuff in your dmz and or edge normally would not need to resolve any of these devices I would think, since they are in dmz really wouldn't have access to them anyway. If you have rules between your vlans you would have to allow for dns between the vlans to your dns.
-
"What would be the best way to leverage just one internal DNS server?"
Point your clients to it, create whatever records you wan in it.. Allow for dynamic registration for devices that support that. Now sure what your not understanding? You don't know how to create a A record in MS dns? You don't know how to allow registration from non ad members?
Your only thing is stuff in your dmz and or edge normally would not need to resolve any of these devices I would think, since they are in dmz really wouldn't have access to them anyway. If you have rules between your vlans you would have to allow for dns between the vlans to your dns.
I know how to add an A record in MS DNS. I'm not sure how to allow dynamic registration from non-ad members but I'm sure I could figure that out.
So for the fe fw, be fw, and edge fw I just need to add static records on the AD DNS server? The HUB and EDGE mail servers do need to resolve each other's hostnames.
And for the fe and be fw, I don't need to change anything in their DNS servers?
Yes, the creation of rules between vlan's is just an easy step using UDP 53.
-
Well I wouldn't want stuff in dmz going to my AD dns.. So you would have to use some other dns for them.. Why would stuff in your dmz need to resolve your internall stuff?
-
Well I wouldn't want stuff in dmz going to my AD dns.. So you would have to use some other dns for them.. Why would stuff in your dmz need to resolve your internall stuff?
The only DMZ server that needs to resolve the an internal server (Hub Transport) is the Edge Transport, that's how Exchange works as you may have known.
-
well then punch a pinhole in your dmz and have it query your AD dns.
-
Now, there's another weird thing that's going on with my DNS. There's nothing wrong with the setup in the dropbox picture I've posted here. Computers in the testlab LAN, when used with nslookup can properly resolve, say, www.google.com.
On my other pfsense box, in another home, when I do nslookup on one of the computers in its LAN it appends the connection-specifc DNS suffix that its LAN connection has. Of course, if the computer gets its DHCP assignment from pfsense, pfsense will assign a connection-specific DNS suffix to it. So let's say, I do "nslookup www.google.com" it returns the result for www.google.com.domain.com, domain.com being my domain. I know that that happens when the address you query is unqualified. So if I query the complete FQDN with the "." in the end, "nslookup www.google.com.", then it gives me a good result. I thought there was nothing wrong with this but why is it not giving me the same behavior as the one above? Take note, the computers in the testlab LAN in the situation above is not in any domain and so they have the exact same setup as the situation in this paragraph.
What gives?
-
I don't know what gives, but all my Windows clients have this behavior. I can:
ping www.google.comAnd underneath the ping resolves an IP address for a real public www.google.com - somehow ordinary programs that want name resolution do it OK.
But if I
nslookup www.google.comSomehow nslookup always sticks on the domain name suffix/es and tries for www.google.com.mycompany.example.com.
So in nslookup I always put the root domain dot at the end:nslookup www.google.com.A quick search found this Microsoft article on how their nslookup works: nslookup www.google.com
Nslookup will always devolve the name from the current context. If you fail to fully qualify a name query (that is, use trailing dot), the query will be appended to the current context. For example, the current DNS settings are att.com and a query is performed on www.microsoft.com; the first query will go out as www.microsoft.com.att.com because of the query being unqualified. This behavior may be inconsistent with other vendor's versions of Nslookup, and this article is presented to clarify the behavior of Microsoft Windows NT Nslookup.exe
