Skip to main content
A
Anonymous_User
Contributor
June 22, 2004
Question

Routing DNS requests

  • June 22, 2004
  • 14 replies
  • 10807 views
**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

    14 replies

    UkWizard
    UkWizard
    New Member
    June 22, 2004
    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.
    A
    Anonymous_UserAuthor
    Contributor
    June 22, 2004
    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
    UkWizard
    New Member
    June 22, 2004
    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.
    A
    Anonymous_UserAuthor
    Contributor
    June 22, 2004
    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
    UkWizard
    New Member
    June 22, 2004
    That doesnt make sense, why would web traffic between .1 and .11 even touch the firewall ? as they are on the same subnet ?
    A
    Anonymous_UserAuthor
    Contributor
    June 22, 2004
    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.
    A
    Anonymous_UserAuthor
    Contributor
    June 22, 2004
    As promised, pictures say a thousand words, maybe these will for me Click here
    UkWizard
    UkWizard
    New Member
    June 22, 2004
    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.
    A
    Anonymous_UserAuthor
    Contributor
    June 22, 2004
    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...
    UkWizard
    UkWizard
    New Member
    June 22, 2004
    this problem is a typical one when you have a rulebase that adheres to the internal and external interface policy method. it is much better when you have complete control over the policies. For example, in checkpoint firewall 1. You have a seperate NAT policy rulebase, so you can translate anything to anything and have complete control over it. I think 2.8 will be different, so i look forward to that.
    A
    Anonymous_UserAuthor
    Contributor
    June 22, 2004
    Oh boy, I' m also looking forward to 2.8... whenever that is -- I haven' t seen any dates, but then again I haven' t looked for them. In any case, I hope support has an interim solution. I can' t imagine I' m the only person that has this sort of a configuration... I don' t think I' m doing anything too out of the ordinary here.
    UkWizard
    UkWizard
    New Member
    June 22, 2004
    2.8 is due on friday, if it isnt delayed again ...
    Adrian_Lewis
    Adrian_Lewis
    New Member
    June 23, 2004
    Friday? I was told Saturday 19th for some strange reason. Anyway, I' m not 100% that I understand what the problem is but have you played around with the DNS shaping features available on the command line? There' s bugger all documentation on it but it works a treat for me when I have internal/external dns lookup problems. You can play with: set firewall dnstranslation ... Alternatively, can you add the real routable IP addresses as secondary addresses to the interfaces of your two DNS servers and multihome? As long as the machines have a default route that is on the 192 net external traffic should go out from the machines with a source ip of 192.x and get NAT' d as normal. Only problems I can see is where you have other VIPs using the routable net that are not on the same physical segment as your dns servers as they will broadcast for each other. I haven' t thought this one out much so don' t jump in. Just thought that some input may be better than none!
    Adrian_Lewis
    Adrian_Lewis
    New Member
    June 23, 2004
    I' m sure there' s an easy way round it. Just got to digest it and analyse. It' s now 05:49, I' ve not gone to bed yet, and I have to see a client in about 4 hours.
    A
    Anonymous_UserAuthor
    Contributor
    June 23, 2004
    I' ve spent a fair bit of time trying to figure out how exactly this needs to be configured. And you' re absolutely right, there should be an easy answer. But Fortinet themselves haven' t given any answers yet either. It' s eluding us all The critical point here is that when packets go internal -> external through the Fortinet and find a matching VIP, it shouldn' t just re-route back internally and wipe out the source IP, changing it to 192.168.1.1
    Adrian_Lewis
    Adrian_Lewis
    New Member
    June 23, 2004
    Quite. I see that as a bug surely? it should either use the VIP address as source or at least the actual 192 address. Anyway - got to go to bed now.
    A
    Anonymous_UserAuthor
    Contributor
    June 23, 2004
    After talking with Toby Renfro and sending some packet captures his way apparently it has been escalated to Mehrdad Mostafavi. Haven' t heard from him yet but I' m anxiously awaiting word on this...
    Show more replies
    Terms & ConditionsAccessibility statement