Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 27 subscribers
  • Views 1313 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Routing failures when HA enabled

Luis Londono

We have an issue on v18 where if we have HA enabled and the auxiliary device is on whether in active/passive or active/active connections to our DMZ network behind the firewall's fail. I spent 6 hours today on the phone with a Sophos tech reconfiguring the HA, looking over all the NAT rules, reconfiguring NAT and firewall rules, changing routing rules, just about everything was done. Thing is nothing worked. When the auxiliary device is on nothing can connect to the servers on the DMZ network, if I turn off the auxiliary device everything works! I can get to the DMZ network servers and there are no issues. 

We really want to be able to have the 2 310 XG firewall's that we have to be in active/active mode and so I'm hoping someone on here has had better luck and maybe some pointers on what needs to be done.

 

My network setup

Internal LAN behind a L3 switch that routes internal traffic which then connects to the XG on Port 5.

DMZ is on a managed switch with no vlans on port 4

Both the XG's are connected to trunk ports on the switches as what the documentation for the HA shows.

 

I see the traffic going from Port 5 to Port 4 but then does not come back. At one point before everything done today and while it was being changed around I would be able to ping the DMZ servers but I could not reach their web sites. 

 

TIA for any help



This thread was automatically locked due to age.
Parents
  • 0

    That sounds like something is messing up with the entire routing.

    Is it possible, while HA is active, to tcpdump on both XGs (or login to the Shell via SSH to both?). 

    You should try to sort out, if you can point any routing issue caused by XG or by your switch. As the Layer 3 switch could actually mess up this scenario (virtual MAC involved, rare cases, which can lead to problems on such switches). 

  • 0 in reply to LuCar Toni

    So I thought I had it figured out last night when I changed the switch that is on the DMZ to not have the firewall ports to be in trunked mode, but this morning its not working again. 


    I ran a tcpdump on both firewall's and was seeing traffic going from LAN to DMZ but not back to the LAN. 

    However I turned off the load balancing on the ha via console and the traffic started working again. I noticed in my DMZ switch that there was only one MAC address entry and that was for the primary XG but no entry for the auxillary firewall. I'm thinking that that is not correct and that it should have both the firewall's in the MAC table unless they are both sharing a MAC address or using a virtual MAC to hide which one it goes to, is that correct?

  • 0 in reply to Luis Londono

    Found my answer to the MAC table question: https://support.sophos.com/support/s/article/KB-000035558?language=en_US#HA-load-balancing-on/off

     

    I still dont understand though why when load balancing is off the traffic works fine

  • 0 in reply to Luis Londono

    Seems like your Switch is not able to handle the vMAC? 

    Basically we are using the same virtual Mac for both ports (for example PortA). 

    If we send data from Appliance 1 with Port A and vMac X, the switch could get confused, that the same vMac existis on another Port. For example Appliance 2 uses on Port A also vMac X. 

     

    https://docs.sophos.com/nsg/sophos-firewall/18.0/Help/en-us/webhelp/onlinehelp/nsg/sfos/glossgroups/HAGlossary.html

    It is a MAC address associated with the HA cluster. This address is sent in response when any of the machines make an ARP request to HA cluster. It is not the actual MAC address and is not assigned to any interface of any unit in the cluster.

    The primary device owns the MAC address and is used for routing network traffic. All external clients use this address to communicate with the HA cluster. In case of failover, the new primary device will have the same MAC address as the failed primary device. The cluster device which has a virtual MAC address acts as a primary device.

Reply
  • 0 in reply to Luis Londono

    Seems like your Switch is not able to handle the vMAC? 

    Basically we are using the same virtual Mac for both ports (for example PortA). 

    If we send data from Appliance 1 with Port A and vMac X, the switch could get confused, that the same vMac existis on another Port. For example Appliance 2 uses on Port A also vMac X. 

     

    https://docs.sophos.com/nsg/sophos-firewall/18.0/Help/en-us/webhelp/onlinehelp/nsg/sfos/glossgroups/HAGlossary.html

    It is a MAC address associated with the HA cluster. This address is sent in response when any of the machines make an ARP request to HA cluster. It is not the actual MAC address and is not assigned to any interface of any unit in the cluster.

    The primary device owns the MAC address and is used for routing network traffic. All external clients use this address to communicate with the HA cluster. In case of failover, the new primary device will have the same MAC address as the failed primary device. The cluster device which has a virtual MAC address acts as a primary device.

Children
No Data