Skip to main content
A
Anonymous_User
Contributor III
July 29, 2011
Question

Not successful with Virtual IP

  • July 29, 2011
  • 3 replies
  • 14660 views
I am having a problem creating a publicly accessible server using a new Fortigate 200B. I am new to Fortinet equipment but have been successfully using Cisco gear for a number of years and am frustrated being a new user again. I hope you might be able to point out what stupid thing I am doing wrong. Short story: I create a Virtual IP and corresponding Firewall Policy for a server on the DMZ. Clients on the LAN can see the server. Clients on the Internet cannot. Bypassing the Fortigate and putting the server directly on the cable modem works fine. From the documentation and tech notes this seems like it should be an easy thing to do. What am I missing? Long story: I have done a factory reset on the Fortigate and tried to create the bare minimum configuration to aid in troubleshooting. I am running “v4.0,build6539,110520 (MR2)” which is the special build of MR2 patch 7 that supports FortiAP’s. I am running in Interface mode (not Switch mode). (This also means I have removed the default DHCP server and default Firewall Policy because they referred to “Switch” as the interface.) I am running in NAT mode. I have created 3 interfaces: WAN, DMZ, and LAN on interfaces 10, 11, and 12. For each interface, I have entered an alias, the IP address and subnet mask (x.x.x.x/y.y.y.y) for that interface, and selected Ping for Administrative Access. On the LAN interface I have also selected HTTPS. Interfaces 3 and 4 are setup as heartbeat interfaces but are not in use. The address I used for the WAN interface is one of the static IP addresses assigned by our ISP. I have created a single static default route to the WAN interface using the gateway address that the ISP assigned as our default gateway address (which is the address of the cable modem). On the Fortigate, in Network - Options, I have added our two internal DNS servers and specified a local domain name. I have created two firewall policies to allow all traffic from the LAN to the WAN and from the LAN to the DMZ. Both of these are “Enable NAT” and “Log allowed traffic”. On the implicit policy, I have selected “Log violation traffic.” Fortiguard definitions are updating. Users on the LAN can reach the Internet. I have placed a test server (JetDirect print server with a Web administrative interface) on the DMZ network. I have set the server’s default gateway address to point to the DMZ interface on the Fortigate. Users on the LAN can reach the test server using its DMZ address. I have created a Virtual IP entry for the test server as follows: Interface is WAN. A different static IP addresses (not the gateway or interface address) assigned by our ISP is the “External IP address” (leaving the second box on that line blank). The DMZ address of the server is the “Mapped IP Address” (again leaving the second box on that line blank). I did not check the port forwarding box. I have created a Custom Service entry for port 80. It allows ports 1-65535 to get to ports 80-80. (This was following the steps in a tech note. I have also tried “ANY” and the built-in HTTP service as destination services.) I have created a Firewall Policy allowing all hosts on the WAN to connect to the test server using the Custom Service. “Enable NAT” is not checked. “Log Allowed Traffic” is checked. Users on the LAN can reach the server using either its DMZ address or its public address. Users on the Internet cannot see the server. I have changed the logging level to Debug. I don’t see anything of interest in the Traffic log on the Fortigate; in fact we don’t see any outside traffic on the log. Although it doesn’t seem like it would be needed, I have created a second Firewall Policy to allow the test server on the DMZ to access Any/Any on the WAN. I have tried both checking and not checking “Enable NAT” for that policy. “Log allowed traffic” is selected. Reconfiguring the server with a public IP address and moving it to the cable modem (bypassing the Fortigate) works fine. We have tried a lot of variations on this theme. It seems pretty basic but isn’t working. What am I missing? Thank you for any light you can shed into my darkness.

    3 replies

    ede_pfau
    SuperUser
    ede_pfau
    SuperUser
    July 30, 2011
    Hi, and welcome to the forums! Nice move from Cisco to Fortinet. You' ll enjoy it eventually. You seem to have a routing problem. All of your steps are well thought of and reasonable. One can see that you have experience in routers and firewalls. But it looks like that the NAT feature on the FGT is not yet clear to you. There are 2 NAT methods available: source NAT (most commonly used) which is enabled in a policy by checking the NAT option, and destination NAT via Virtual IPs. Both can be combined if necessary. To address incoming traffic to an internal host using a public IP on the WAN interface you employ a VIP. You create the VIP object and then use it as the destination address in a policy from the interface on which the VIP is defined to the target interface (where the target server is located). A VIP changes the destination IP address ONLY - packets are routed to a different address but keep their source IP. If the public host responds to this private IP address traffic gets lost.
    I have created a Firewall Policy allowing all hosts on the WAN to connect to the test server using the Custom Service. “Enable NAT” is not checked.
    And if your DMZ server runs with a private IP address like ' 192.168.x.y' , how would a host on the internet determine the route back to it? You definitively need to check the NAT option in the outgoing policy here. There is one special case here: if traffic is coming in to a VIP, and the VIP is NOT port forwarding, then the return traffic will be source NAT' ted automatically when traversing the VIP. But in no case will traffic originating from the DMZ server be NAT' ted unless you enable the NAT option.
    I have created two firewall policies to allow all traffic from the LAN to the WAN and from the LAN to the DMZ. Both of these are “Enable NAT” and “Log allowed traffic”.
    The traffic from LAN to DMZ does not need (source) NAT as the route back to the LAN is well known to the FGT - it' s directly connected. As it is configured now all traffic from LAN to DMZ appears to come from the LAN' s interface IP. You don' t need a custom service definition for an allready predefined service. HTTP will do. Please delete the ' wan->wan' policy immediately if not already done. Please try to change your config accordingly and report back. If you do, please include the VIP definition, the static routes and the policy (get them from the CLI). The Traffic log is not the appropriate tool to debug this. Fortigates come with a built-in sniffer (tcpdump alike). But you probably won' t need it now. Do you have the FortiOS Handbook for your FortiOS version? You get it at http://docs.fortinet.com . All the major concepts are clearly laid out there and a lot of realworld examples given. If unsure come back to the forum.
    A
    Anonymous_UserAuthor
    Contributor III
    August 1, 2011
    Ede, Thank you very much for the thorough reply. I was fortunate enough to be able to spend some time with a Fortinet engineer on Friday. It does not seem like the config was the problem. For whatever reason, the Fortigate was just not responding to packets destined to the Virtual IP address. After much fooling around, the Fortinet engineer changed the address of the Fortigate WAN interface to be the same as the WAN address of the test server Virtual IP. Once this was done, the Fortigate started to pass traffic to the server. When the interface address was returned to its original value, the Fortigate continued to pass traffic. It isn' t clear what caused the problem. Perhaps the Fortigate was failing to respond to ARP requests for the Virtual IP address, or perhaps there was some sort of compatability snag between the Fortigate and the SMC Cable Modem, or perhaps we will never know... As of this morning, both the cable modem and Fortigate have been restarted and they are continuing to pass traffic. I' m going to build out the config on the Fortigate adding other servers and features. Hopefully this was just a one-time oddity. Thank you again for your response. It is truly appreciated.
    ede_pfau
    SuperUser
    ede_pfau
    SuperUser
    August 2, 2011
    Thanks for the follow-up. I' m glad you got it working. These things should not happen at all - you do everything according to the book and the box just doesn' t do it. Happened to me too, but that was a long time ago (v2.80MR8). I bet the Fortinet SE has had quite a difficult time (or humor). While you' re at building your configuration please consider the points I' ve made in my previous post. The non-forwarding VIP saves you the effort to check NAT on the outgoing policy but please be aware that this is a special case. If you forward certain ports only you' ll have to have NAT checked. And NAT un-checked on the LAN->DMZ policy. And the custom service. I know that sometimes while debugging you put everything into question, even standard port 80 service definitions. I would' ve done the same probably. But it' s not the culprit here. Using the standard service definition has the advantage that you may assign the HTTP proxy to a non-standard port, and it' ll still work (though I haven' t tested this yet). If you need starting hints come back to the forums, there are a lot of skilled and helpful colleagues around who will help you out.
    Terms & ConditionsAccessibility statement