Routing DNS requests

[#1]

**ADDITION, please see the following illustration: click here ** Ok, maybe I' m missing the obvious here but here is the story: SITUATION ==================== Two DNS servers sit behind the Fortinet unit. All servers run in the private network and all have 192.168.1.x addresses assigned to them. No DMZ is being used at this time, just internal (my servers) / external (the internet). The two DNS servers act as public nameservers for the websites I host. One of the DNS servers is a primary (with internal IP 192.168.1.6) and the other a secondary (with internal IP 192.168.1.7). All of the DNS entries have public IP' s the records they host as they serve up sites on the public internet. This includes the nameserver records NS1.myhost.com (69.90.x.1) and NS2.myhost.com (69.90.x.2). The primary nameserver is set to push updates (MSDNS) to the secondary nameserver (MSDNS). It is by default set to only allow transfers to listed nameservers, which should be fine because the external ip of ns2.myhost.com is listed in each primary zone. I have VIP' s set on the Fortinet... (ns1.myhost.com) VIP set 69.90.x.1 -> 192.168.1.6 (ns2.myhost.com) VIP set 69.90.x.2 -> 192.168.1.7 ------------------------------------ The Problem ==================== After a new secondary zone is created on the secondary server, it seems that it doesn' t actually go out on 69.90.x.2 and come in on 69.90.x.1 to get the update from the primary. It just goes internally using 192.168.1.1 Thus the request to update gets denied. I am using the EXACT same configuration as I had working with a Netscreen unit (don' t get me wrong, I like Fortinet a LOT better). Why doesn' t the traffic get routed out on the correct IP... why does it use the Fortinet box internal IP? ------------------------------------ Sorry for the long winded post, I didn' t want to leave out any details and would really appreciate any thoughts people could give this. Thanks so much, Chris

[UkWizard]

It is a lot easier to just allow that the primary servers IP update rights on the secondary. Why even bother routing it through the firewall for no reason. This can only use up resources on the firewall anyway. Otherwise try this, but i do not know if it will work or not. Create an external address with the primary' s Ext IP in it. Create a policy rule at the top that says; Ext -> Int, Source= Address from above(primarys ext ip), Dest= VIP of secondary, NAT=enable. This may override the box and nat behind the correct IP. Its a long shot i know, but it may just work.

[#3]

First off, thanks so much for taking the time to respond. I really apprecite it! The reason that I can' t just set each zone on the primary to allow updates to A) any server or B) the IP 192.168.1.1 is because there are many sites being hosted and new ones added each day by my hosting automation system. By default, the transfer property is set to " all nameservers listed on the nameservers tab" and unfortunately that can' t be changed. Which it could. Essentially, the automation system writes the primary zone file on the primary DNS server, writes a secondary zone on the secondary which then asks the primary for all the zone file information. Interesting idea with the external IP and new policy, but wouldn' t that damage notmal external -> internal traffic from the public internet for normal DNS lookups? The problem here is that the Fortinet uses it' s own internal address when routing traffic internally. For example, if I go and visit a webpage from one of my other webservers on the network and view the web log I get the following: 2004-06-22 13:59:47 W3SVC5655 MERIT650 192.168.1.11 GET /index.coo - 80 - 192.168.1.1 HTTP/1.1 Mozilla....... See how it records it as coming from the Fortinet IP and not the IP of the visiting server? Not even the correct internal IP is listed, let alone the external. Here is the same situation getting back to DNS, the following is what I get on my debug log for DNS: 01:04:05 3E84 PACKET TCP Snd 192.168.1.1 0000 R Q [0580 REFUSED] (19)mydomain(3)com(0) TCP response info at 0262CAC0 Socket = 916 Remote addr 192.168.1.1, port 42941 Time Query=1466582, Queued=0, Expire=0........ =========================== Thanks again for your help!

[UkWizard]

what are the following IP' S; 192.168.1.1 192.168.1.11 And no it shouldnt interfere with normal lookups, as the source is the external IP of the primary server. So conly traffic from the primary to the secondary will be affected by that rule. what it could be is that the outgoing rule is natting the ip as well, bit of a tricky one really. Would need to know the exact sequence of how the inners work to give you the full answer. could try a int -> ext rule as well saying no nat, where source is the primary and secondary is the destination. that may prevent it from natting if placed above the standard outbound nat rule. I will see if i can test a theory here, if it get time.

[#5]

192.168.1.1 is the internal IP of the Fortinet box itself, all my servers have 192.168.1.1 set as the gateway in their network settings. It is not assigned as an IP to any server. In that web log 192.168.1.11 is the internal IP of one of my web servers. I mentioned the web log result in my previous post to demonstrate that from another server on teh internal network when the traffic flows through teh Fortinet unit it always registers as coming from IP 192.168.1.1, it seems to ignore the real IP and just use its own. I am going to follow this post with a pictoral representation of my configuration. It should make things much clearer. Thanks again! Chris

[UkWizard]

That doesnt make sense, why would web traffic between .1 and .11 even touch the firewall ? as they are on the same subnet ?

[#7]

On the other server it would have to do a quick DNS lookup for that site... at which point it would see the A record pointing to an external IP... so it goes to the gateway to try and visit the IP 69.50.x.x (external IP of other webserver) and the fortinet routes it back internally. It works fine, the page comes up and everything... which is great. But during that brief route on the Fortinet box, it switches up the source IP to 192.168.1.1 THis is what I can' t explain and this is exactly why the DNS transfers fail, it doesn' t recognize 192.168.1.1 as a listed nameserver IP.

[#8]

As promised, pictures say a thousand words, maybe these will for me Click here

[UkWizard]

Nice pix, but i understand now, i have also confimed the problem on my testbed here. Thats a weird one. Tried all sorts to get it working, am sending an email to support. Will let you know. as i am curious on this one as well now.

[#10]

Hearing that has just made me so happy. Trying to describe my config made me feel like a lunatic... I shoudl have posted pics right from the get go! Thanks for taking so much interest in this...