CLI pings cable modem GW but can't ping or traceroute beyond

[JJLatFortinet]

I'm setting up a new Fortigate 70D and have a basic problem connecting to the internet.  It seems like a pretty simple setup and I would appreciate some help.  It's running in Standalone/NAT mode.  wan1 is connected directly to a Cisco wifi-router/cable modem from Cox.  I've assigned FG70D wan1 a static IP of 192.168.0.9/24 with DGW 192.168.0.1.  The internal network ip range is 192.168.1.0/24.  The FG static route is set to 192.168.0.1.

config router static edit 1 set gateway 192.168.0.1 set device "wan1" next end

From the CLI, I can ping 192.168.0.1, but I can't ping or traceroute 8.8.8.8.  "100% packet loss" and 3 stars on every hop of the endless traceroute.  If I connect a laptop to the same port on the cable modem, the laptop can ping, traceroute, and roam the net.  The FG70D CLI can't do anything.  I've tried setting the macaddr to the same as the laptop, thinking that perhaps the cable modem had some mac restriction, but still no joy.  I have a policy (for testing) for "internal -> wan1" to allow all sources, all destinations, all services.  I'm not sure such a policy matters for the CLI, but internal to wan1 traffic doesn't work either.

I've rebooted the cable modem multiple times too.  I assume there's something simple that I'm missing.  What should I look for?

[rwpatterson]

Double check the subnet mask on the laptop when it's connected directly to the Cisco cable modem. I'm guessing that's the culprit. Everything else looks right from this angle. Are you sure that there is a policy on the Cisco for the IP address you statically assigned? Cox may only allow the IP address that the laptop is getting dynamically. I know it appears that there is a full 24 bit subnet outside your Fortigate, but the cable company may be doing some funky behind the scenes filtering/blocking. I know Verizon FIOS does just that. Think about it this way. You are paying for a single IP address. If you could just wing any one in, you could conceivably take as many as you want. Not a very good business model.

[JJLatFortinet]

Thanks Bob.  I don't think that's the issue.  FYI, this is a Cox Business Internet with one public dynamic IP and one public 29-bit block.  The cable modem DHCP assigns 192.168.0.10-192.168.0.129 on the internal side.  The FG70D won't pick up an IP from the cable modem DHCP even if I pre-assign an IP to its mac on the cable modem, so I've been manually setting the FG70D IP.  If I connect a laptop that has never been connected to the cable modem before, it picks up the next IP and pings and traces out just fine.

I don't know how traceroute actually works, but it seems to me that if I can ping the default gateway, shouldn't a traceroute at least give a reply from the default gateway as the first hop?  Like this:

FGT70D3Z1500xxxx # exec traceroute 192.168.0.1

traceroute to 192.168.0.1 (192.168.0.1), 32 hops max, 72 byte packets

 1  192.168.0.1  1.029 ms  0.693 ms  0.592 ms

 

But, if I traceroute to 8.8.8.8, I get this:

FGT70D3Z1500xxxx # exec traceroute 8.8.8.8

traceroute to 8.8.8.8 (8.8.8.8), 32 hops max, 72 byte packets

 1  * * *

 2  * * *

 3  * * *

 4  * * *

 5  *

I've tried a factoryreset and used the most basic wizard settings and it still won't pick up an IP from the cable modem DHCP.

[Toshi_Esumi]

First thing I would do is running a just simple sniffing like "diag sniffer packet any 'host 8.8.8.8' 4" then run pining from another admin session or from a device behind the FG. Then you can know if it's actually getting out through wan1 and what source IP those packets have.

But if the cable modem/router is operating in routing mode how can you utilize the additional public subnet from Cox you mentioned? The cable modem/router needs to know what private IPs to map those public IPs or port mappings. You can't use them at your FG. It's generally meant that the modem is supposed to be in modem/bridge mode and your FG is to terminate the dynamic public IP. Then you can utilize the additional public subnet/IPs at the FG whatever you want to utilize.

[MikePruett]

Will your provider not place the modem in bridge mode so you can just let the FortiGate handle everything instead of it being NAT'd being the modem and then your devices being NAT'd again?

[JJLatFortinet]

Thanks Toshi and Mike.

First, here's what I got on the diag when I tried to ping from a second admin session:

FGT70D3Z1500xxxx # diag sniffer packet any 'host 8.8.8.8' 4

interfaces=[any]

filters=[host 8.8.8.8]

52.457666 wan1 out 192.168.0.9 -> 8.8.8.8: icmp: echo request

To answer your questions about the bridge mode, I'm actually replacing an older FG50B and I was hoping to test most of the settings before putting the FG70D into production.  The cable modem has one physical port in bridge mode for the 29-bit public IP subnet going to the FG50B and the remaining 3 ports and WiFi (which is disabled) are in router mode for the single dynamic IP.  My next test is to set the FG70D to handle the bridged 29-bit subnet and then tweak it in production.  I don't do this stuff very often, so I'm no expert, but it just seems like this should have worked.

[Toshi_Esumi]

Since it's going out through wan1 with the source IP you set, the problem is on the cable modem/router not on the FG. You mentioned the FG didn't get DHCP IP somehow. That sounds fishy to me. I would get help from the provider why your ping packet/or reply doesn't get through the modem/router if you don't have a proper manual of it. It might be dropping packets if the source is not in DHCP range. But this is just my guess.

[ede_pfau]

Or it could be that the FGT is in the modem's "DMZ", that is, all traffic is handed through without routing or any other alteration. Then, traffic with a private source address is going out to the internet where it dies...

Could you try and enable "NAT" in the 'internal'->'wan' policy on the FGT?

[JJLatFortinet]

ede_pfau wrote:

Or it could be that the FGT is in the modem's "DMZ", that is, all traffic is handed through without routing or any other alteration. Then, traffic with a private source address is going out to the internet where it dies...

Could you try and enable "NAT" in the 'internal'->'wan' policy on the FGT?

Thanks Ede.  I have tried to set the FG70D in the cable modem's DMZ, with the same results.  NAT is enabled in the policy.  But I wonder, since I'm trying to do the traceroute from the CLI, is any internal -> wan1 policy actually involved?

[Toshi_Esumi]

You can test is by configuring a PC with the same IP 192.168.0.9 or other .8, and so on. You of course need to unplug the FG if you use the same .9 IP. My guess is you would see the same symptom your FG is having. By the way policies on the FG wouldn't affect to the traffic generated from FG itself, like pinging and tracerouting from the FG.