Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
generaltab
New Contributor

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

Hello

 

I just replaced my old FortiGate 100 with a new FortiGate 90D and there are still a few things that behave differently than before.

 

When I’m connected to my FortiAP with a phone I’m unable to retrieve mail from my internal mail server, or any other internal servers by name, but I can access external sites. My phone is on “wireless” interface 10.10.10.10/255.255.255.0 and my servers are on “internal” interface 192.168.1.254/255.255.255.0

 

Perhaps related to this, or not, the desktops on my LAN are able to reach external websites, but are unable to reach sites on internal servers by FQDN (eg: [link]http://apps.domain.com/bigtime).[/link] They can reach sites on internal servers by UNC (//whitney/bigtime)

 

I have a feeling I need some additional policies. Any ideas?

 

Thanks

21 REPLIES 21
generaltab
New Contributor

Thanks, ashukla.

 

I should take a step back before I configure as you've provided. Are Virtual IPs even needed in my case? Say I want to limit external access to our mail server by creating a policy that allows only SMTP. Do I need a Virtual IP for that, or just an Address Object and a policy referencing that object?

 

Thanks.

generaltab
New Contributor

Thanks again. Before I configure these policies for VIP, I'm beginning to suspect that I don't need VIP for my scenario to work. I have 3 servers that require both internal and external access. One is hostname "diablo" (int. 192.168.1.11, ext. 64.145. 110.91). Access to it should be limited to https. Can I create a policy that accomplishes that without creating a VIP for it? Thanks.

ede_pfau
SuperUser
SuperUser

No you can't.

The VIP will

- bind the public IP to the external interface (answering to ARP requests)

- translate the destination IP from the public IP to the internal IP

 

The last point is necessary as private IP addresses are not routeable (cf. RFC1918). So with a policy 'wan->internal' you could not reach the private address as it's not routed to you.

The salient point is: how do internal users connect to the DMZ'ed server, by name or by private address or by public address?

Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
Dave_Hall
Honored Contributor

If this was me, I'd stick both old and new configs into WinMerge to see what the differences are.   But by the sound of it, I have a feeling that the old config had DNS translation enabled on it, or at least it is something that could be used to resolve your issue.

 

 

NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C

NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C
generaltab
New Contributor

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.

ede_pfau
SuperUser
SuperUser

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
What's the deal with VIPs on your side? Just configure them, put them into policies as destination addresses and go for it. It's that simple.

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.

Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
generaltab
New Contributor

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

Dave_Hall
Honored Contributor

Just curious to know what your methodology for determining what has changed between the old and new configs?  (I use WinMerge myself.)

 

If you follow KB# FD33976, it indicates setting up the ext interface to "any" on the VIPs, then setting up two fw policies to the same VIP from different interfaces. The code may look similar to this...

 

config firewall vip
    edit "diablo"
        set extip 64.145.110.91
        set extintf "any"
        set mappedip 192.168.1.11
    next
    edit "langley"
        set extip 64.145.110.92
        set extintf "any"
        set mappedip 192.168.1.7
    next
    edit "whitney"
        set extip 64.145.110.93
        set extintf "any"
        set mappedip 192.168.1.9
    next
end
config firewall policy
    edit 0
        set srcintf "external"
        set dstintf "internal"
            set srcaddr "all"
            set dstaddr "diablo"
        set action accept
        set schedule "always"
            set service "FTP" "HTTP" "HTTPS" "Minecraft"
    next
       edit 0
        set srcintf "internal"
        set dstintf "internal"
            set srcaddr "all"
            set dstaddr "diablo"
        set action accept
        set schedule "always"
            set service "FTP" "HTTP" "HTTPS" "Minecraft"
    next
    edit 0
        set srcintf "external"
        set dstintf "internal"
            set srcaddr "all"
            set dstaddr "langley"
        set action accept
        set schedule "always"
        set service "HTTPS" "SMTP" "IMAP" "HTTP"
    next
       edit 0
        set srcintf "internal"
        set dstintf "internal"
            set srcaddr "all"
            set dstaddr "langley"
        set action accept
        set schedule "always"
            set service "HTTPS" "SMTP" "IMAP" "HTTP"
    next
    edit 0
        set srcintf "external"
        set dstintf "internal"
            set srcaddr "all"
            set dstaddr "whitney"
        set action accept
        set schedule "always"
            set service "HTTPS"
    next
       edit 0
        set srcintf "internal"
        set dstintf "internal"
            set srcaddr "all"
            set dstaddr "whitney"
        set action accept
        set schedule "always"
            set service "HTTPS"
    next
end

 

Personally, I'd would want my users to use the internal IP address for "public" servers if I can -- without the need to talk to those servers via the Fortigate: in which case I'd probably set up local cname records for diablo.domain.com, pointing to diablo.domain.local, etc. This is assuming I was accessing these servers by FQDN or hostname.  Alternately, dnstranslation maybe an option if I had no control over the DNS servers.

config firewall dnstranslation
edit 0
set dst 64.145.110.91
set netmask 255.255.255.255
set src 192.168.1.11
edit 0
set dst 64.145.110.92
set netmask 255.255.255.255
set src 192.168.1.7
edit 0
set dst 64.145.110.93
set netmask 255.255.255.255
set src 192.168.1.9
end

NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C

NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C
ede_pfau
SuperUser
SuperUser

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.

Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
ede_pfau
SuperUser
SuperUser

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

Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors