DDNS in WAN interface not updating right ip

[#1]

Hello, I' m from AbAKUS, official fortinet partner/reseller. We just bought 6 forti30b for a customer in order to make ipsec tunnels. firmware is version 4.x tunnels are working fine (6 forti30b to one forti200a).. forti30b are running on a dynamic DSL connection the issue is, the DDNS function in the wan interface of forti30b' s is updating the ddns record to the actual wan ip which is 192.168.x.x (behind the fortinet is another router) and not the real public ip.. what sense does that make ? is there something i am missing here ? i need it updating to the public ip thanks for your quick help, it' s kind of urgent (i say " it' s working" because i temporary installed some soft ddns updater on each pc)

[ede_pfau]

Hi, that depends on the method which is used to determine the " real" WAN IP. Apparently, the FG reads off the IP of the wan interface and communicates that to the DDNS. If you have an additional router _in front of_ the FG (as seen from the LAN) then the FG cannot see the router' s external IP. It would have to connect to an external server (like whatsmyip.com) to get it read off. Relying on some external source is clearly inacceptable for a reliable service. Solutions: - the real gateway has to do DDNS, in your case the other router - you configure the router only as a bridging modem and let the FG do the PPPoE, and the DDNS part BTW, do you really mean " FG200A" and not " FG200B" ?

[#3]

200A not 200B mmh in many cases, behind our fortis we have some other router and we can' t just let it run in bridge. For example, here in Belgium, the classic ISP modem/router has television connected, so you can' t just let it run in bridge mode. Of course it can' t do ddns..or i would be half so angry. the fortigate could connect to some script running on the official fortinet page for example..i don' t see why this would be unreliable ? i did this years ago with some linux box..was some little 5 lines html script this all means, the ddns function is only usable if forti' s wan is public..sorry, one time again it doesn' t make any sense. whether it update to some real public ip, whether it updates to nothing...in any case not to some class C ip.. it just feels buggy that' s a big issue for us, since we' re beginning to sell much of those 30B' s for business/home users that needs tunnel to their office and that pretty much everyone in belgium has dynamic ip + those shitty i-can' t-get-rid-off isp modem' s... i' ll be very disappointed if u say me there' s no way, this is a function u expect in a 50€ device no matter what we are talking about approx 500€ devices and not 1 of them..hundreds we already sold such bullshit just pisses me off, really

[ede_pfau]

Easy, alvoryx, I' m not the trash can. Some thoughts on this: - for dail-in IPSec VPN from remote to company you don' t need DDNS. For the scenario you describe I don' t see any reason why the initiating IP should be known in advance. Once the tunnel is connected it is in fact known to the central VPN gateway and can be logged. So what? - use your energy to enter a feature request with Fortinet with the following construction: DDNS should get the WAN IP' s value from the FortiGuard server it connects to. There, Fortinet logs the IP anyway. Connection to the FortiGuard server is needed anyway, and it' s a trusted host. So that might work if Fortinet is willing to invest in this feature. - the BS part is not the FG30B but the el cheapo-cable router which is not capable of doing DDNS - how come that your company sells hundreds of FG' s and only now finds out that some feature is missing?

[#5]

sure that it' s not ur fault, so don' t take it personally, but i' m a little bit pissed off -in this case, i don' t want a dial-in..i need tunnels to be initialazable from both sides -the isp modem router role is from my point of view, to establish the internet connection. forti wan is in the dmz and that' s it. saying that ddns should be the role of the device connected to the net is 1) not necessary true (while it seems the most logic) and 2) rejecting the shit on someone else shoulders. many cheap devices can do that, for me it wasn' t even a point to take in consideration. -normally we make tunnels between 2 fix IP' s (for a business, the way it should be done). so it' s indeed the first time i need to handle with this case, and like i said i don' t want dial in. with " hundreds" i don' t mean that we have to get this to work on hundreds, but that we thrusted fortinet for a long long time now i come to the consideration that even if the fortigate had the function we are talking about, this had to be linked with some cron tool since his own wan doesn' t change. so maybe it would take a little bit more than a few lines. anyways but come on..am i the only one trying to do this ? na ja :\

[rwpatterson]

If there are PCs/Servers on the LAN side, use the DDNS provider' s custom software (such as with DynDns.org) to setup the association. It' s a small bit of software which reads the IP address from the public side that runs on any Windows box. Not ideal, but it works.

[ede_pfau]

Congrats, you found the reason why this isn' t implemented yourself. Now that you know that this feature isn' t available and probably will not for the near future you will have to make some compromise. IMHO the least hassle would be to implement dial-in VPN with auto-dial. OK, the initial tunnel setup would have to come from the remote side; but after that the tunnel is kept up all the time. From the central site you would not be able to notice the difference. You might even configure the remote FG to ping into the central LAN (network>interface>ping server), just to make sure. But I don' t think this would be necessary at all. No software on any remote host, no dependency on OS and more. So, I' d set up a sample FG at home and tweak the VPN settings until you get an always-up tunnel. @Bob: they' re already using a software agent now.

[rwpatterson]

I have to stop posting on Monday mornings.... ;)