[SOLVED] UTM Updates with private IP on WAN interface.

[Adrien]

Hi all, I have difficulties in cases where the FGT' s WAN port had no public IP address but a private one (having the FGT behind an Metropolitan Network; with private address). I have found different topics for this problem but i was not able to find the solution / best way for a Fortigate 310B in V5 build 291. Here is the topology (i can' t connect to the MAN/WAN equipments): MAN <--> 310B is interconnected by static routes. WAN <--> MAN (10.63.32.13) <---> (10.63.32.14) WAN MY-FG310B <---> Internal Networks, DMZ.... Default route on the Fortigate unit is 0.0.0.0/0.0.0.0 dst 10.63.32.13 on WAN Port. 10.63.32.14 can' t be routed/NAT-ed over internet; I have already ask to my provider. Using source-ip command in CLI: Works for DNS lookup, Sflow, NTP.... using " source-ip A.B.C.D" where source-ip is one of my public ip located on port2 " DMZ" . Unfortunatly i was not able to update. If I trace packet for DNS or NTP, my source ip is A.B.C.D (well) but for a force update my source ip is 10.63.32.14. NTP Exemple (work):

 # diagnose sniffer packet any ' host 145.238.203.14'  4
  0.634692 port1 out A.B.C.D.123 -> 145.238.203.14.123: udp 48
  0.646904 port1 in 145.238.203.14.123 -> A.B.C.D.123: udp 48
 

UPDATE Exemple (don' t work)

 #diagnose sniffer packet any ' host 208.91.112.68'  4
  8.432481 port1 out 10.63.32.14.7033 -> 208.91.112.68.443: syn 4151528419 
  11.431059 port1 out 10.63.32.14.7033 -> 208.91.112.68.443: syn 4151528419 
  17.431062 port1 out 10.63.32.14.7033 -> 208.91.112.68.443: syn 4151528419 
  

I can resolve but not go out:

 firewall-a # execute traceroute update.fortiguard.net
 traceroute to update.fortiguard.net (96.45.33.88), 32 hops max, 72 byte packets
  1  10.63.32.13  1.740 ms  1.705 ms  1.600 ms
  2  *
 

Normal; 10.63.32.0 is not routed over internet. Is there a mistake in my config? What can I do for this? Using a radius proxy server: To forward requests from my 310B directly on update.fortiguard.net:443 via DMZ interface (which is routed on internet, of course). I was not able to configure it over Apache2, I have no answers from the update.fortiguard.net server. My fault? Using VDom Maybe is this the only way to solve my problem? I have no Fortigate v5 for tests but if it' s the only one solution, via internal FGT routing, I will try. Let me know if it' s the solution for me. Using Local-in policy I Think this is not the solution, i have just read the docs and I think that it can' t resolve this kind of problems. Thanks for your suggestions; Sorry for my poor English. Regards, Adrien

[Sean_Toomey_FTNT]

What you need to do is add a secondary IP to your WAN interface, and it needs to be a public routable IP (aka not a private IP address). Then you route this /32 back to the firewall from the router in front of it. Then you update FortiGuard in the CLI as emnoc suggested. That is exactly what the source-IP option is for. You set the public IP here and it will work. I had this exact same scenario for many enterprise installations. I should note this option went away for a little while in earlier 5.0.x patches. It is in 4.3, 5.0.x later patches, and 5.2. I don' t personally know why it went away (I suspect the option below was the intended replacement) but I do know it came back by strong customer demand. Something else you can do, if you have a FortiManager, is to have the FMGR be the local FortiGuard server, and under Central Management in the GUI there is a checkbox to use FortiManager for all FortiGuard communications. Either one will work. Cheers!

[Adrien]

Hi Sean, I have no Forti Manager, but you gave me the solution. Problem was in my Version. I have tested 5.0.7, 5.0.8 and 5.0.9, there are no ip-source parameter for updates. I upgraded to 5.2 and now I can activate Source-ip in " Fortiguard" CLI Menu. For the moment the Public IP given to the paramter " source-ip" is NOT on Wan, but on DMZ. It works like a charm for Web and Email filtering (and was already working for DNS and Analyzer). For the other updates (IPS, Antivirus and Vulnerabilites) it don' t work for the moment. I' m working on, and if there are no solution I Will put a Public IP /32 on WAN Interface. (I listen all your good suggestions about putting a public IP on WAN, but this wasn' t my initial question.) Thanks for all Adrien

[Sean_Toomey_FTNT]

Hi Adrien, Hrm, I thought they had put the option back in 5.0.x versions, I must have been mistaken. I did know for sure it was there in 5.2 You should be able to use the public IP on the DMZ interface, the firewall won' t care if it' s WAN or DMZ. Just so long as you can set the source-IP to use this interface and it routes back to the firewall from the device ahead of it. Can you try an " exe update-now" and make sure it tries to update AV/IPS?

[Adrien]

Hi All, Here is the final answer from my Forti support ticket. For remembers, my problem for web filter updates was solved (use 53 port with source-ip directive for dns) but it was not resolved for AV Updates (443 port) I' ll try this solution provided by the support as soon as possible. Regards, Adrien ------------------------------------------------------------------------------------------ create VDOMs on the Fortigate. - backup the Fortigate' s configuration - enable VDOM usage on the dashboard (Fortigate will reboot) - create a new VDOM for the aggregated interfaces (port 2-3-4-5 if I remember right) - disconnect the interfaces, delete the policies regarding these interfaces and move them to the new VDOM - create a VDOM link between the 2 VDOMS (assign IP addresses to them like 20.0.0.1/30 and 20.0.0.2/30) - create a static route from the new VDOM to the root (default) using the root VDOM' s virtual link IP - create a static route from the root VDOM to the new VDOM using the new VDOM' s virtual link IP - reapply the policies into the new VDOM (outgoing interfaces now needs to be the inter-VDOM-link virtual interface instead of port1 which was internet) and reconnect the interfaces - set up the management VDOM to the new VDOM (config global <enter> config system global <enter> set management-vdom name_of_the_new_VDOM_here <enter> end <enter> end <enter>) Why this? - Requests from the Fortigate itself now goes out on port1 which is NOT NAT-ed and the request will never finish the 3 way handshake - When there is a new VDOM with a public IP the management VDOM will choose the closest interface to the internet according the to the routing table and since everything is routed towards the vdom-link the interface will be chosen is the public one while going through your network (private one) and going out to the net using the real public without NAT. This won' t eat much of the CPU/memory of the unit but will solve your issue.

[Adrien]

I forgot to tell you that the only solutions for me (and for the forti support) are: - Public IP on WAN (Was not my question and not possible for me) - Make a NAT on the provider router for the private interco IP. - VDOM Regards,

[Adrien]

SOLVED Using Vdoms: a) All LAN/DMZ subnets/interfaces are over Vdom1 b) Private IP on outgoing interface is over Vdom2 Vdom1 <-- static route --> Vdom 2 Next steps was: Declare Vdom 1 as root (for AV updates) - I NAT outgoing ip interface of Vdom1 (Private IP used by vdom routing) on the vdom2, using a public DMZ IP present on vdom1. Permit All from Wan to Vdom1 on the Vdom2 Permit All from Vdom1 to wan on the Vdom2 All my other rules are on vdom1 All updates works now without using " source-ip" directive. Regards, Adrien