New Member

Question

WAN1 STOPPED WORKING

Forum|Forum|30 days ago
June 15, 2026
5 replies
151 views

WAN1 STOPPED WORKING

- I have two FortiGate 60F setups as stack (HA1 and HA2)
- I have Juniper router
- I have a Rogers modem with 2 public IP 187.x.x.x/30 and 184.x.x.x/30
- link 1: Rogers modem port1 > FG60F WAN1
- link 2: Rogers modem port2 > Juniper router
- I also have a 2nd ISP (TELUS) for failover
- WAN1 link shows Green UP in the GUI; WAN1 led light is blinking green/yellow

Problem: WAN1 is not pulling the public ip whether in static or DHCP

TS:
- reboot the modem, connect my laptop with correct IP details used in FG60F (SM, GW and IP) = WORKING
- leave Juniper plugged in = WORKING
- turned off the modem for 10mins, removed the laptop, reconnected the FG60F = FAILED
- Juniper still working
- Replaced modem, reprovisioned and performed laptop testing again and still working.
- Tried disconnecting Juniper from Rogers modem and leave only FG60F connected = FAILED
- Internet works because of WAN2 (TELUS)

Question:
1. Why WAN1 not pulling the public IP? why there is no internet from WAN1?
2. Why my laptop works and not the FG60F?
3. Will it be a MAC address issue?

Note: before the incident, Rogers had a network update (node migration) and after that it suddenly stopped working. The fact that my laptop works with the FG60F ip assumes that there is no issue with the modem (per Rogers).

Badly need help or suggestions. Thanks.

Toshi_Esumi

SuperUser

I would try sniffing WAN1 port to see if DHCP handshake is broken or not. If static, to see if it’s one way.

Toshi

sjoshi

Staff

Hi @FRNZZZZ

you can take pcap on wan1 and dhcp debug.

SSH1:

If FortiGate is the DHCP client:

diagnose debug reset
diagnose debug application dhcpc -1

diagnose debug console timestamp enable
diagnose debug enable

To stop the debug:

diagnose debug reset
diagnose debug disable

SSH2:

diag sniff packet wan1 ‘port 67 or port 68’ 4 0 l

Also since you informed it works with laptop is there any MAC binding done on the ISP side?

Thanks, Salon

F

FRNZZZZAuthor

New Member

Originally, WAN1 is configured with a static IP (184.x.x.x). I only temporarily switched it to DHCP to test whether the router would obtain an address automatically.

Yes, my laptop is able to connect successfully, and I don’t believe there is any MAC binding on the ISP side. The laptop works after the modem is rebooted.

sjoshi

Staff

in that case setup the static ip.

Are you able to ping the remote ISP GATEWAY

are you seeing the arp entry

Thanks, Salon

msanjaypadma

Staff

Hi @FRNZZZZ ,

Can you configure a random HA group ID on the FortiGate device and then check the current status?

example:

config system ha
set group-id 120 <----- (XX is an integer value from 0-255).
end

Refer below article :

If you have found a solution, please like and mark it as solved to make it easily accessible for everyone.

Thanks, Mayur Padma

F

FRNZZZZAuthor

New Member

will that changes moved to HA2? Sorry I just know basic configuration with 60F. I am just new to this. As much as possible I dont want to have any downtime. My thinking is that if I set the HA group ID to 120, HA2 will takeover and there is nothing connected to WAN1 or WAN2 of the 60F.

msanjaypadma

Staff

Hi @FRNZZZZ ,

I assume that "HA2" is the hostname of the secondary device within the HA cluster.

The HA Group-ID configuration will be synchronized with the secondary device, and that will not trigger any HA failover. The only change will pertain to the MAC address.

If you have found a solution, please like and mark it as solved to make it easily accessible for everyone.

Thanks, Mayur Padma

christian_89_

Explorer II

Everything in your description points to one thing: the MAC address. The laptop and the FortiGate use the same IP, mask and gateway, so the only variable left is the MAC, and that is exactly where an HA cluster behaves differently from a single device.

In an HA cluster, WAN1 does not use the 60F's burned-in MAC. FGCP changes the current hardware address of each cluster interface to an HA virtual MAC, and for HA group IDs 0 to 255 that virtual MAC is built from the prefix 00:09:0f:09 plus the group ID and an index. Your laptop presents its own NIC MAC instead. Rogers, like most cable/DOCSIS providers, binds the service to the CPE MAC it sees, and the node migration you mentioned almost certainly reset or changed that binding on their side. So now the modem and CMTS forward for the laptop's MAC but drop the FortiGate's 00:09:0f:09 virtual MAC. That is why static and DHCP both fail, why the link still shows green (layer 1 and 2 to the modem are fine, the drop is upstream), and why a 10-minute modem power-off did not fix it, since that clears the modem cache but not necessarily the CMTS binding. cisco Fortinet

Confirm it in two minutes with only the FortiGate connected:

Static: diagnose sniffer packet wan1 'arp' 4 0 l. You will see the FortiGate ARP for the gateway and get no reply. Check the source MAC in those frames, it will be 00:09:0f:09:xx:xx.
DHCP: diagnose sniffer packet wan1 'port 67 or port 68' 4 0 l together with diagnose debug application dhcpc -1. DISCOVER goes out, no OFFER comes back.
See the MAC the cluster presents: diagnose hardware deviceinfo nic wan1 (Current_HWaddr) and diagnose sys ha mac.

Fix. Make the FortiGate present the MAC that Rogers accepts, which is the laptop's working MAC. Important detail for HA: you cannot use set macaddr here, because the macaddr option is not available in a functioning cluster. The HA-compatible command is set virtual-mac, which overrides the FGCP virtual MAC assignment on that interface: cisco Fortinet Community

config system interface
    edit "wan1"
        set virtual-mac <the laptop MAC that works>
    next
end

Then power-cycle the modem, off for longer than 10 minutes. If the CMTS binding is sticky, Rogers may need to clear or re-provision the CPE MAC on their side. One caveat: once you clone that MAC onto WAN1, do not reconnect that same laptop to the same modem at the same time, or you create a MAC conflict. The cleaner long-term option is to pick a MAC and have Rogers bind the service to it.

On the group-id suggestion: changing it does work in the sense that it mints a new virtual MAC, and Fortinet documents changing the HA group ID as the way to resolve virtual-MAC conflicts. But it is a guess. If Rogers is bound to one specific MAC, a different virtual MAC still will not match. Setting virtual-mac to the known-good MAC is deterministic, changing group-id is a gamble. cisco

To your worry about downtime: neither change triggers a failover. The group-id or virtual-mac change syncs to the secondary, and the only thing that changes is the MAC, as the staff said. The cluster sends gratuitous ARP to make the upstream relearn the new MAC, so expect a brief WAN1 blip during the change, but nothing moves to HA2 and the secondary stays secondary. Amazon Web Services

The Juniper on the modem's second port keeps working throughout because it presents its own NIC MAC, which fits the MAC-binding picture exactly.

CFR_

F

FRNZZZZAuthor

New Member

VSF_FG60F_HA1 # diagnose hardware deviceinfo nic wan1
Description :FortiASIC NP6XLITE Adapter
Driver Name :FortiASIC NP6XLITE Driver
Board :60F
lif id :0
lif oid :64
netdev oid :64
Current_HWaddr 00:09:0f:09:01:00
Permanent_HWaddr 94:f3:92:46:a2:d4
========== Link Status ==========
Admin :up
netdev status :up
autonego_setting :1
link_setting :1
speed_setting :1000
duplex_setting :0
Speed :1000
Duplex :Full
link_status :Up
============ Counters ===========
Rx Pkts :476759884
Rx Bytes :68961338220
Tx Pkts :18181451
Tx Bytes :4555853948
Host Rx Pkts :443829367
Host Rx Bytes :20690269681
Host Tx Pkts :4190425
Host Tx Bytes :1046840191
Host Tx dropped :0
FragTxCreate :0
FragTxOk :0
FragTxDrop :0

diagnose sniffer file attached. I will try the changing the MAC later after work hours. Thank you @christian_89_

console-output-CLI-Console-(1).txt

christian_89_

Explorer II

Your capture confirms it. This is the MAC, not DHCP and not routing.

Two things from the output:

WAN1 is presenting the HA virtual MAC, not the box's real MAC. diagnose hardware deviceinfo nic wan1 shows Current_HWaddr 00:09:0f:09:01:00, the FGCP virtual MAC for group-id 1, while the burned-in Permanent_HWaddr is 94:f3:92:46:xx:xx. Your laptop uses its own NIC MAC. That is the only difference between the two.
The ARP sniff is the proof. Your upstream gateway (the .137 in your /30) keeps asking who-has for your WAN1 IP (.138) over and over across the whole capture and never resolves it. That one recurring line is the failure: Rogers cannot learn the MAC behind your WAN IP. Everything else in those 9700 packets, the flood of who-has from 70.70.x, 50.67.x, 24.x and so on, is just the normal broadcast noise of the shared cable segment and is a red herring.

So the link is up and the FortiGate is receiving fine, but the upstream will not resolve or accept the cluster's virtual MAC. After the node migration Rogers bound the service to the MAC it last saw, your laptop's, and it now drops the 00:09:0f virtual MAC. That is exactly why the laptop works on the same IP and the cluster does not.

Fix, present the MAC Rogers accepts. In HA you cannot use set macaddr, it is blocked in a running cluster, so use set virtual-mac:

config system interface
    edit "wan1"
        set virtual-mac <the laptop MAC that works>
    next
end

Then power-cycle the modem, off for more than 10 minutes. If it is still bound, Rogers has to clear or re-provision the CPE MAC on their side. Do not plug that laptop back into the same modem afterwards, or you will have two devices sharing one MAC.

To verify, run the same diagnose sniffer packet wan1 'arp' 4 0 l again. You want to see .137 resolve .138 once and stop repeating, and then traffic flows.

CFR_

Sign up

Login with SSO

Login to the community

Login with SSO