Need an internal -> internal policy for LAN access to internal servers??

Thanks, Ede & Dave.

None of the servers are on the DMZ. All are on one internal interface. The only difference I found between the old and new FortiGate was the "Enable DNS forwarding from" option in the old one. My LAN’s clients can find the server by “diablo” and “diablo.domain.local”, but not “diablo.domain.com” (even though it resolves to the correct external IP). I’d like them to be able to reach that machine by any of those names or IP (internal & external) as they could with the old FortiGate. If VIP is required, I’ll try adding policies according to this KB. It still seems like more than should be necessary, as if I'm missing something fundamental.

Thanks again.

generaltab, if you look at the old config you'll notice you were using VIPs:

config firewall vip
    edit "diablo"
        set extip 64.145.110.91
        set extintf "external"
        set mappedip 192.168.1.11
    next
    edit "langley"
        set extip 64.145.110.92
        set extintf "external"
        set mappedip 192.168.1.7
    next
    edit "whitney"
        set extip 64.145.110.93
        set extintf "external"
        set mappedip 192.168.1.9
    next
end

I already posted that you need to employ VIPs to access internal servers from the WAN. That's a fact and won't change disregarding how many more posts we will put in here.

If you had followed the advice given here previously and had compared the old and new configs you  would have saved yourself (and us) a lot of time.

Answer: Yes, internal -> internal policies are now required for internal access to internal servers by external IP. Thanks again.

Thanks, Ede. I've had VIPs set up on the new FortiGate from the beginning. They're configured identically to the old FortiGate. What's changed is the device's behavior, not the configuration. Internal servers can be accessed from the WAN just fine. However, internal servers can't be accessed by their external IPs by internal users, as demonstrated by the following attempts to reach the internal mail server by internal and external IP:

H:\>ping -n 1 mail

Pinging mail.aliquot.local [192.168.1.7] with 32 bytes of data:

Reply from 192.168.1.7: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.1.7: Packets: Sent = 1, Received = 1, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms

H:\>ping -n 1 mail.aliquot.local

Pinging mail.aliquot.local [192.168.1.7] with 32 bytes of data:

Reply from 192.168.1.7: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.1.7: Packets: Sent = 1, Received = 1, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms

H:\>ping -n 1 mail.aliquot.com

Pinging mail.aliquot.com [64.145.110.92] with 32 bytes of data:

Request timed out.

Ping statistics for 64.145.110.92: Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),

That's the behavior that changed between the old and new FortiGates.

Thanks again

Thanks for clarifying, now I get it. Without the new config I was misled that VIPs weren't in use. Sorry.

The old FortiOS version was v3.00 MR something...so that's been quite a while.

How then did you set up the 'internal->internal' policy - I assume you are not using the VIP as destination address? If you would you'd have to define it on the 'any' interface or else it wouldn't be allowed.

(man do I wish I could delete my own posts!!)

Thanks Ede, Dave

I'm using the VIP as the destination address as this article advises. I wanted to avoid using external IPs from the LAN, but even with a local record for mail that resolves to the server's internal IP, things on the LAN seem to insist on using the external IP. So until that's resolved I needed at least a temporary solution.

Now, similarly, my wireless users can't sync mail (unable to reach our server's external IPs) while connected to our FortiAP, but I'll post that to the wireless forum.

Thanks again

The wireless problem was resolved by switching to bridge from tunnel mode so the wifi users are on the internal subnet. I thought it would work the other way with my wireless -> internal and wireless -> external policies.