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]

Sounds to me like the following: As your secondary DNS server send off a packet with a source ip on the 192 net and dest on the 69 net the fg takes it and puts it into it' s routing module. The routing module thinks at this time that the packet needs to have it' s source ip NAT' d as it looks like it' s going to come out of the external interface at some point. This packet then enters the Firewall module and the Stateful session gets set up and no other higher layer processing goes on unless you have the IDS turned on on the internal interface. It is then passed back to the routing module that still thinks that the source ip has to be NAT' d when it reaches it' s egress interface. The routing module knows that the destination is another VIP and so the destination ip also needs to be translated. At this point, the fg thinks that the packet has to have it' s destination ip NAT' d to the internal 192 ip corresponding to the destination VIP for your primary DNS server. It also thinks that the packet is due to have it' s source IP NAT' d because of the initial decision that the packet is going from an internal interface to an external interface. If this were the case and the dest IP were not a VIP, it would substitute the original packet' s source ip with the external interface' s ip address. Instead, the fg does not realise that the packet is actually coming back into the internal network but still thinks that the source IP has to be NAT' d to the egress interface' s IP. Hence you get the packet coming back out of the internal interface with a source ip incorrectly NAT' d to the internal interface IP and the destination IP correctly NAT' d to the internal IP of your primary DNS server. Unfortunately, I have no fix for the fg' s behaviour but: If you were to multihome and add both internal 192 net and 69 net VIP addresses to your DNS servers' interfaces with no default route on the 69 net, when the secondary tries to contact the primary, it should (I think) do the following: When the 2ndary realises that it has to contact the primary via the 69 net, it will realise that it should not send this packet out to the fortinet with a 192 source ip as it it also locally on the 69 net. When this packet leaves the 2ndary' s interface it will broadcast for the other 69 address. When it knows the destination MAC address of the primary, the packet leaving the 2ndary' s interface will have a source ip on the 69 net and so be accepted by the primary. When there is communication between the internet and one of these servers, both machines, due to the fact that there is a default route on the 192 net and not the 69 net will send out the packets with a source ip on the 192 net as is the case now to the fg' s interface and get NAT' d as should be. This is very fiddly but I have a feeling that it will work at least. The only step that you will need to take is to add the 69 addresses and subnet masks as secondary IP addresses to any of your internal hosts that mapped to VIPs and that need to communicate with each other using the VIP addresses as both source AND dest.

[Adrian_Lewis]

UKWizard: Based in London? Want a new job?

[UkWizard]

Adrian, Funnily enough i am looking, getting the five year itch at my current place. I dont live in london, but can work there (commutable, work in london a lot already). Have you got vacancies then ?

[#5]

ORIGINAL: Adrian Lewis Unfortunately, I have no fix for the fg' s behaviour but: If you were to multihome and add both internal 192 net and 69 net VIP addresses to your DNS servers' interfaces with no default route on the 69 net, when the secondary tries to contact the primary, it should (I think) do the following:

You are nothing short of brilliant. It works like a charm, everything propagates between the two servers fine as soon as I put in the external DNS IP into the IP list in TCP/IP properties. Case closed this is now fixed!!!! Just out of curiosity though... are there any security or other implications to having an external IP assigned to the machine along with internal addresses? Just wondering. Thanks again for all your help everybody! I' m so happy right now!

[UkWizard]

Merit, Thats a workaround but not something i would consider a permanent solution. Leave the fortinet call open if you can, as i would like to see the results of there ' fix' . Thanks

[#7]

Agreed, I want to see what Fortinet comes up with as well. I don' t like having external IP' s assigned on my private network. Just seems sketchy. Off hand though, it shouldn' t cause any security implications since NAT is still protecting it.... would it?

[#8]

ORIGINAL: Merit

ORIGINAL: Adrian Lewis Unfortunately, I have no fix for the fg' s behaviour but: If you were to multihome and add both internal 192 net and 69 net VIP addresses to your DNS servers' interfaces with no default route on the 69 net, when the secondary tries to contact the primary, it should (I think) do the following:

You are nothing short of brilliant. It works like a charm, everything propagates between the two servers fine as soon as I put in the external DNS IP into the IP list in TCP/IP properties. Case closed this is now fixed!!!! Just out of curiosity though... are there any security or other implications to having an external IP assigned to the machine along with internal addresses? Just wondering. Thanks again for all your help everybody! I' m so happy right now!

Well I found out a pretty good reason to not have an external IP assigned on a an internal server with NAT IP' s.... my server couldn' t communicate with another server (owned by another hosting company on the other side of Canada) that had an IP on the same subnet. Pretty nasty side effect. Anyways, I have re-opened my support ticket as this issue perists and I found another problem it causes.... When one of my mail servers sends out e-mail for a newsletter from a website it sends some e-mails to users on my primary mail server (communicating on the external IP). However, the primary mailserver sees the incoming connection as 192.168.1.1 NOT the proper external IP and marks the message as spam because it fails an SPF check. Yet another side effect of this persisting problem.

[UkWizard]

Not that i can think of, but depending on how you setup the external IP subnet masks, you may have problems accessing any external IP addresses from them two servers. Like the firewall address and any other vips you may have setup. As the two servers would think the entire subnet was local and therefore not send it out to the default gateway. Also be careful that the two servers do not populate the Dynamic DNS (if you have one) with the wrong IP addresses.

[Adrian_Lewis]

UK Wizard, If your 5 year symptom is still itching in a few months, there may be a position available. Still in startup mode but things are going well and will be expanding soon. As you point out, yes there will be routing issues with this fix but only to IP addresses on the same subnet - i.e VIPs, the external interface of the fg, and the router address if the fg is not using PPPoE. Any other dest network and the servers will use their 192 addresses as source ip. I don' t like the fix either but it works for now until Fortinet sort out the issue.

[UkWizard]

Adrian, I am currently on a large fortinet project that will take me through the october anyway, let me know if anything pops up.