Options

Migration problems from M200 to M290

Hello,

We bought a M290 recently and I've migrated our M200 configuration by following this guide:
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/basicadmin/config_file_use_new_model_wsm.html

I've removed the Feature Key and imported the new Feature Key, changed the OS Compatibility to 12.6 or higher and changed the Firebox Model to M290.

The import succeeds, but when I switch to the M290, our devices no longer have internet.

The M290 can ping google.com etc. but my laptop for example can no longer ping google.com.

I did a traceroute google.com and It only went to my core switch. It should've also gone through Watchguard.
My core switch can ping google.com.

My config looks like this:
int 0 : external 1 (public ip)
int 1 : Trusted (vlan 1, 33, 100,...) - connected to the core switch

If I switch back to the M200 everything works perfectly.

I've checked the VLAN configuration (compared the config files) and as far as I can tell, the VLAN config is the same.

Any idea what the problem could be?

Comments

  • Options

    Reboot your core switch.
    Most likely it has the MAC addr of the old firewall int 1 instead of the for the new firewall.

  • Options

    Tried that. Unfortunately, it still doesn't work.
    My support case already got escalated 3 times and they even put the priority to Critical..
    I've migrated the config 4 times, even did it once while I was on the phone with support. I don't know anymore, could my M290 be defective?

    When I switch back to the M200 it just works..

  • Options

    Have you tried using a different interface as External?

  • Options

    I haven't tried that yet, I'll try that tonight.

  • Options

    You could try a test config with a laptop connected to Trusted and External connected to an internal switch.
    This would just to be able to see if you can get traffic through the firewall, out a specific external port.

    A hardware test. If it is successful, then you know that it isn't a hardware issue.
    If not successful, then it is a hardware issue.

  • Options

    Have you tried running a Firebox Configuration Report, to see if that presentation makes anything jump out for you?
    I'd test a vanilla new config, and try another port for External interface.

  • Options
    james.carsonjames.carson Moderator, WatchGuard Representative

    In almost every situation where I've run into this, it's because the upstream ISP device is holding onto the MAC address of the old firewall/router.

    If this is the case, you'll see the M290 arping via TCPDUMP and not getting a reply. You can do this in Firebox System Manager under Tools -> diagnostic tasks. Select TCP Dump from the task menu and select advanced options.
    assuming your external interface is eth0, you can use an argument like
    "-nei eth0"
    or
    "-nei eth0 arp" if you just wanted to see arp traffic. If you're seeing ARPs from the firewall being broadcast with no response, then your ISP's device is most likely the culprit.

    If it's easier, you can also set the MAC address on the external interface to be what it was on the old firewall. See:
    https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/networksetup/interface_speed_set_c.html

    You can find the MAC address in Firebox System Manager under front panel (just expand your interface) or in the WebUI under Dashboard -> Interfaces.

    Just use the MAC from the old firewall on the new one via the override setting.

    -James Carson
    WatchGuard Customer Support

  • Options

    @james.carson said:
    In almost every situation where I've run into this, it's because the upstream ISP device is holding onto the MAC address of the old firewall/router.

    If this is the case, you'll see the M290 arping via TCPDUMP and not getting a reply. You can do this in Firebox System Manager under Tools -> diagnostic tasks. Select TCP Dump from the task menu and select advanced options.
    assuming your external interface is eth0, you can use an argument like
    "-nei eth0"
    or
    "-nei eth0 arp" if you just wanted to see arp traffic. If you're seeing ARPs from the firewall being broadcast with no response, then your ISP's device is most likely the culprit.

    If it's easier, you can also set the MAC address on the external interface to be what it was on the old firewall. See:
    https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/networksetup/interface_speed_set_c.html

    You can find the MAC address in Firebox System Manager under front panel (just expand your interface) or in the WebUI under Dashboard -> Interfaces.

    Just use the MAC from the old firewall on the new one via the override setting.

    That's probably not the problem. But I'll give it a try.
    The M290 can reach the internet (via Diagnostics pinging google.com/8.8.8.8) and I've also configured (untagged) vlan 100 on eth3. Plugged my laptop into eth3 and set a static IP with the M290 as my default gateway. It could also reach the internet. It couldn't reach the internet when I set it to DHCP.

    Support told me the problem is internal routing since traffic doesn't go to the M290. But it all works when I switch back to the M200.
    So if the problem is internal routing, the M200 also shouldn't work.. But it does.

  • Options

    According to the support:

    In older fireware versions the firebox did not use the VLAN ID for spoofing/routing purposes so this is likely while the M200 works to pass the traffic while the M290 doesn't. Disregarding the VLAN ID is considered a security issue so that is why the firebox on newer fireware versions will only route properly tagged VLAN traffic.

    If I do a tcpdump on the M200 (-nei eth1 host 10.100.5.10) and use 10.100.5.10 (VLAN 100) to ping 1.1.1.1, I do not see a VLAN ID.
    If I ping 10.11.0.1 (M200 interface for VLAN 33), I can see the VLAN ID 33.

    We tested some stuff on a test setup.
    Here's what we tested:
    Client 10.100.8.6 connected to a switch (which is connected to the core switch) and we configured the M290 as the default gateway on the client
    10.100.8.6 (vlan 100) pings 10.11.0.1 (vlan 33, M290 IP) -> in the pcap we can see the VLAN ID is 100

    Client 10.100.8.6 connected to a switch (which is connected to the core switch) and we configured the core switch as the default gateway on the client
    10.100.8.6 (vlan 100) pings 10.11.0.1 (vlan 33, M290 IP) -> in the pcap we can see the VLAN ID is 33

    So when using the core switch as our default gateway, the VLAN ID changes. If we use the M290 as our default gateway, the VLAN ID stays the same.

    I'm guessing this could be the reason it does not work, but I'm not sure how to fix it yet.
    My core switch is a Cisco SX550X by the way.

  • Options
    james.carsonjames.carson Moderator, WatchGuard Representative

    @zapp If that's the case, your cisco switch is likely dropping the VLAN tag -- you'll check the documentation for your switch to see how to get it to pass the VLAN tag as you expect.

    -James Carson
    WatchGuard Customer Support

Sign In to comment.