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]

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.

[#3]

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]

2.8 is due on friday, if it isnt delayed again ...

[Adrian_Lewis]

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]

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.

[#7]

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]

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.

[#9]

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...

[UkWizard]

I have a call raised on this as well, but what the hell they want packet captures for is anybodies guess. They only have to try it to see the problem, they are just wasting our time. Grrrr

[#11]

The the packet capture thing was kind of tricky because they requested that I do it late at night when there is minimal traffic. Unfortunately there' s always a fair bit of traffic going through the system and I had to segment some of the IP' s in such a way that there was nothing but DNS traffic going on the IP that was being sniffed. In any case, they have captures from both the primary and slave DNS server to see exactly what' s going on. Just a sample 18.663621 192.168.1.1.53923 -> 192.168.1.12.53: udp 122 0x0000 0004 0001 0006 0009 0f30 08cd 0001 0800 .........0...... 0x0010 4500 0096 e4ee 0000 7f11 d30a c0a8 0101 E............... 0x0020 c0a8 010c d2a3 0035 0082 a22c 0000 2400 .......5...,..$. 0x0030 0001 0001 0000 0000 0d73 6f6d 656e 6577 .........somenew 0x0040 646f 6d61 696e 036f 7267 0000 0600 01c0 domain.org...... 0x0050 0c00 0600 0100 000e 1000 4b03 6e73 310f ..........K.ns1. 0x0060 0000 0000 0000 0000 0000 7374 696e 6703 XXXXXXXXXXX. 0x0070 636f 6d00 0a68 6f73 746d 6173 7465 720d com..hostmaster. 0x0080 736f 6d65 6e65 7764 6f6d 6169 6e03 6f72 somenewdomain.or 0x0090 6700 7773 8ffa 0000 0e10 0000 0384 0009 g.ws............ 0x00a0 3a80 0000 3840 :...8@