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

[Adrian_Lewis]

UK Wizard, Good luck. Will keep you posted.

[UkWizard]

johns99, the tests i did here, was with two Nats configured, and i still had the problem. Could you explain what your setup was like, and what was happening ? In case its another bug ....

[Adrian_Lewis]

I think that what johns99 is recommending is what you are already doing. When you set up the VIPs you can set either IP to IP translation or specify a port translation if you need to host more than one internal server behind the same external IP. From your screenshots you are already doing straing IP to IP translation (NAT) and not port forwarding (PAT). I' m assuming that the reverse lookup problems that he was experiencing is when external mail servers do a name to ip dns lookup to see if the server is who it says it is. if you set the VIP as a PAT then when the internal server initiates any traffic to the internet then it will not use the VIP as the source ip but use the default policy, most likely using the external IP of the FG. I don' t think the two are related but if johns99 would like to clarify we can look into it.

[#5]

Adrian, your description is exactly right in terms of the scenario I encountered. I haven' t gone through this entire message chain --- it sounds like the VIP config is posted and is already fully NAT' d.

[#6]

Merit, I had something like this with reverse DNS lookup issues for my SMTP server. The solution was to do a full NAT as opposed to a PAT. NAT will show the same address outbound as inbound...PAT will not.

[#7]

Sounds like that could have somethign to do with it, but how do you designate complete NAT versus PAT? Thanks for your help! Chris

[#8]

On the Edit screen for Virtual IP Mapping, select Static IP (as opposed to Port Mapping). As Adrian noted, it appears that this is how your DNS VIP entries are set up since the VIP summary screen shot you posted does not show any port details assoicated with those entries. Still, it' s worth doublechecking since many DNS operations require that the DNS server is verified to be the start of authority which requires reverse lookup resolution.

[#9]

Sorry if someone already responded this (didn' t want to read the whole story of respondents) but it seems pretty obvious that NAT is enabled on the Policy for the VIP entry on each server). Use the VIP don' t use NAT on the policy. The servers will see the Correct public IP when surfing and or delivering UDP 53 content to the internet... Erase ARP everywhere, it may provoke unexpected results when switching boxes, NS to FG. (If your internet router wasn' t rebooted from Netscreen to Fortigate, then do it, somehow this has had issues with customers in the past...ARP and hard to decode L2 stuff stored in the router' s DRAM) My .5 cents

[#10]

Appreciate the response! Thank you... Unfortunately the issue is when not communicating between the Fortigate and the public internet (it sees the address correctly), but when communicating between VIPs. For example: Mail server A (69.90.xx.200 / 192.168.x.2) sends a message to a Mail server B (69.90.xx.300 / 192.168.x.3). Mail server B sees the incoming connection not as 69.90.xx.200 but as the gateway IP of 192.168.1.1

[#11]

Sorry, didn' t get the question Have you tried with separate IN-EXT Firewall policies for each server using IP Pool NAT (probably not even NAT from a Firewall Policy for each server at the top of the rulebase, I' ve never tried that before), because the First email server will try to see the other one through the Firewall but it will also NAT back to the VIP of the second one right? If you try to go to www.whatismyip.com from each server you must see the VIP IP address you configured for each one of them. Note that' s INTERNAL to EXTERNAL traffic. If you' re not seeing it matching address then there' s something wrong somewhere... However I think that will be ok and the NAT Pool or No Nat will assign the right external address. My .5 cents..