Multiple IPs on one Interface - Beginner Questions

[#1]

Hi everybody. First I want to say I' m new to this Forum, I' m not a native English speaker, however I read many of Fortinets manuals trying to understand the basics of FortiOS but I cannot solve some Problems so I hope you can help me. I have a IP-pool from my ISP and until now I had only one external IP active and managed to reach my different internal Servers via VIPs and Port forwarding which is quite annoying. Since I' ll get a second Webserver soon and I don' t want another :8880 suffix to my FQDN I' m trying to figure out how to manage multiple IPs on my WAN Interface. Some Information: 1) We are talking about a FortiWifi 80CM running on OS 4 MR 3 2) My WAN interface has a IP range and I added the adresses I want to ditribute as secondary IPs with /32 range e.g. 170.170.170.50/28 (WAN interface) Secondary IP adresses: 170.170.170.51/32 170.170.170.52/32 3) I created VIPs for both external IP and the corresponding internal IP e.g. 170.170.170.51 -> 10.0.0.51 4) I created a policy allowing the traffic (e.g. port 80 / HTTP for my Webserver) from WAN to INT My internal Interface is running in switch mode and naturally is connected to our main switch where all other device and servers are connected to. I can ping the " new" adress but I cannot display the test-Webpage I have created. Would you recommend changing the mode from switch to interface and connecting the servers physically? Is there any major mistake in my configuration? Basically, all I need is NAT or do I forget some important thing? I really appreciate some help! Thanks in advance

[ede_pfau]

Hi, and welcome to the forums! ItotallyunderstandthatyouarenewtoFortinetbutthatdoesntmatterweallstartedasnewbies! </humor, German kind> Yes, there is a small mistake in your config. If you define a secondary IP address then the interface will respond to queries to it, e.g. via arp. The VIP construct in FortiOS does exactly the same but combines that with destination NAT. So you have 2 interfaces/hosts responding, the FGT and the internal server, which leads to confusion. For security reasons the use of secondary IPs is disencouraged whenever there is a better way. So your setup will do with VIPs only, for all public IP addresses except the principal WAN IP. As you do have enough public addresses for your internal server(s) there is no need to configure them as port forwarding - use just the address translation without port forwarding. Added benefit: the VIP' ed server will respond to ping now (if the policy permits). You protect the internal hosts via policies and UTM as usual. " Best practice" would be to put the servers on a physical port of their own (i.e. into a DMZ) and not allow traffic from DMZ to internal LAN. This way, if a server get hijacked the damage would be limited to the hosts in the DMZ. For your setup this would mean near to nothing effort. You' re welcome if you have more questions.

[#3]

Hi and thanks for your quick reply! So, what I basically did now was deactivating the secondary IP adresse, thus leaving all requests to my 2nd IP for the VIP policies to manage. I switched off the port forwarding and for test purposes created a policy which allows all traffic from that VIP 170.170.170.51 wan1 to my internal IP 10.0.0.51 int. However I still can' t reach the Webserver via the external adress :/ The policy is at the top of the list. Is there maybe another conflict possible? Best Regards

[ede_pfau]

1. to clarify: the policy looks like this: source IF: WAN1 source addr: ALL dest IF: internal dest addr: myVIP (!) service: whatever NAT: disable so the VIP needs to be defined on the WAN1 interface. 2. The webserver needs a default route to reach the internet.

[#5]

aaaahh. That did the trick! My policy did nothing more than allowing traffic between the external and the internal (mapped) IP which of course isn' t what I wanted... Thank you very much! ...und jetzt seh ich auch gerade dass du auch aus Deutschland kommst

[ede_pfau]

Glad it works now. This forum is a self-help platform for Fortinet users from all over the world. To benefit from other users' experience it only takes some knowledge of English. So it' s quite OK that we didn' t switch to German. Imagine we were from Thailand or Tonga - who could follow then? After all, it worked fine.