Incorrect egress interface when doing ping?

Hi, I have an active-backup firecluster, and connected to WG1 (active) the CORE1 switch and connected to WG2 (backup) the CORE2 switch.
Both switches are connected via a clag.

I have created the VLAN 1000 as transport VLAN between the networks where the switches are the gateway and where the watchguard is the gateway and set as untagged on the interface connecting between the switches and the watchguards.

The IPs would be as follows:
On the watchguard, the VLAN 1000 interface has the IP 10.10.10.105/29.
Core1 has the IP 10.10.10.106/29
Core2 has the IP 10.10.10.107/29
And both cores have a vrrp with the virtual IP 10.10.10.108/29
The default gateway of the cores is the 10.10.10.105

The problem I have is that if I try to do a ping from core1 to the WG IP or to any IP that is routed by the WG, everything works perfect and I don't lose any ping.
If I ping from the WG to the core1 IP, same thing, everything perfect.

But if I do the same test from core2, out of 100 pings, I still get 10 in a row, and then none. In the traffic monitor I see that the ping arrives, so it seems that what it does is not to return.

To clarify that when I make the pings from the CORE, they are presented with the own IP and not the virtual one of the vrrp.

If I make a ping from the WG to the IP of core2, the same thing, of 100 they answer 10 in a row as much, sometimes more or sometimes less.
However, if I activate the advanced options and force the ping to be done from the vlan interface 1000, the 100 pings arrive without problems.

It seems as if Watchguard does not know where to send the traffic back, but only when it is core2 the destination.
I have looked at the ARP table and I see the IPs with the correct macs.

Can anyone tell me what is going on?

Thank you very much.

Regards,

Comments

  • For the record, what firewall model do you have and what Fireware version is the cluster running.

  • Hi, it's a pair of M470 with version 12.7.1.

  • james.carsonjames.carson Moderator, WatchGuard Representative
    edited February 2022

    If you're using the ping tool in the diagnostic tasks dialog of the firewall, it's not particularly smart about where it originates the pings from. Traffic from it originates from a hidden rule called Any From Firebox.

    If you want to specify an interface, choose advanced options when you select the ping tool, and specify the argument:
    -I

    So, if I wanted to ping from my public IP 64.74.30.182, to 1.2.3.4, I'd use
    -I 64.74.30.182 1.2.3.4

    (Since formatting and fonts are weird, and to avoid any confusion, the -I is a dash followed by an uppercase i.)

    Same applies for internal interfaces, etc. You can also specify secondary IPs in the interface, so long as the firewall owns that IP you're using as the source.

    -James Carson
    WatchGuard Customer Support

  • Hello, the problem is not only with the ping, but with the traffic in general, that when it goes or comes to CORE 2 from the watchguard or vice versa, packets are lost, and this happens to get from one IP to another IP within the same mask (10.10.10.105/29 to 10.10.10.107/28 and vice versa).
    The thing is that I see the traffic arriving to the watchguard through the traffic monitor, but it seems that it does not know how to return because I have no answer.

    Thank you,

    Regards.

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @Aredondo
    If the traffic is leaving the correct interface, that's the portion of the traffic the firewall can control. If it's coming back somewhere else, I'd suggest checking the equipment that's sending it there.
    The Firebox will drop asymmetric connections.

    -James Carson
    WatchGuard Customer Support

  • Hello @james.carson
    The problem is that the device sending the traffic is the CORE2, and I see that it reaches the watchguard through the traffic monitor, but it is the watchguard itself that does not seem to find the correct interface to respond, despite having only one with this VLAN.
    Could it be something related to asymmetric traffic? Can I disable this protection to test?

    Thanks for your help,

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @Aredondo
    The firebox doesn't support asymmetric traffic at all. There is no option to enable this.

    -James Carson
    WatchGuard Customer Support

Sign In to comment.