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

Can't reach servers when secondary node is alive

Hey Everyone,

So at home I have 2 ESXi boxes.  Well first lets do our best to explain my network.

Dell 48 Port Switch
3 VLANs
     Internal, DMZ, Wireless Bridge

Server 1
HP DL385 G2 ESXi 5, 6 NICs (1 Internal, 1 WAN, 1 DMZ, 1 Wireless Bridge, 1, HA) 4 Virtual Switches, Internal, WAN, DMZ, Wireless Bridge, HA
Astaro Primary
5 NICs (Internal, WAN, DMZ, Wireless Bridge, HA)
Several VMs on Internal
1 VM on DMZ

Server 2
HP DL385G2 ESXi 5, 6 NICs (1 Internal, 1 WAN, 1 DMZ, 1 Wireless Bridge, 1, HA)  4 Virtual Switches, Internal, WAN, DMZ, Wireless Bridge, HA
Astaro Secondary
5 NICs (Internal, WAN, DMZ, Wireless Bridge, HA)
2 VMs on Internal
2 VMs on DMZ

The HA is linked directly over a crossover cable between the two servers.

So here is the problem.  The servers on the DMZ on Server 2 cannot be reached.  No matter what changes I make to my config I cannot reach these servers.  Well I can if I log into the DMZ server on Server 1 I can reach the other DMZ servers.  I cannot however reach them from outside/inside directly.  If I shut down my secondary HA node.  Then everything works just as it is designed.  But as long as that secondary is up then nothing works.

I am open to all suggestions here.  One idea I thought to try out was to put the secondary HA node on its own direct internal LAN link.  Where it gets its own virtual switch, the last available NIC on the server and link to the switch.  I don't see why that would be necessary but at this point I'm willing to try anything to get this working 100%.  Thank you all in advance for your help with this.


This thread was automatically locked due to age.
  • Ok so after reading this thread

    https://community.sophos.com/products/unified-threat-management/astaroorg/f/52/t/28777

    and then this site

    T3CHNOT3S: Astaro Security Gateways, High Availability, and vSphere Virtual Switches

    Disabling the MAC stuff does indeed fix the problem.  Now all I have to do is write a quick init script to do this at boot.  Or a cron perhaps?  What are your guys thoughts on this?  The reason for that is upon reboot it goes away.

    Thanks.
  • Hi, 

    That's odd, I thought all 'cc' commands are persistent across reboots.

    Barry
  • I dunno maybe it does and I just need to be more patient during the reboot. When it starts up and does the initial sync then its screwed up but it seems to settle down and open back up.
  • Hi thefuzz4

    I've had the same problem a few months ago. With the cc command on both Virtual Firewalls the Problem has been resolved. I can reboot/shutdown/start the Firewalls without a Problem.

    You also don't need a script or something, the cc command persist the reboot.

    btw: Some People have suggested that the Problem comes from the Virtual Switches which have an integrated Logic, which blocks outgoing/incoming Traffic if the Mac-Address is known on a VM on the same Switch. (not sure, it's a long time ago [:)] )
  • Hey Everyone,  So at home I have 2 ESXi boxes.  Well first lets do our best to explain my network.  Dell 48 Port Switch 3 VLANs Internal, DMZ, Wireless Bridge  Server 1 HP DL385 G2 ESXi 5, 6 NICs (1 Internal, 1 WAN, 1 DMZ, 1 Wireless Bridge, 1, HA) 4 Virtual Switches, Internal, WAN, DMZ, Wireless Bridge, HA Astaro Primary 5 NICs (Internal, WAN, DMZ, Wireless Bridge, HA) Several VMs on Internal 1 VM on DMZ  Server 2 HP DL385G2 ESXi 5, 6 NICs (1 Internal, 1 WAN, 1 DMZ, 1 Wireless Bridge, 1, HA)  4 Virtual Switches, Internal, WAN, DMZ, Wireless Bridge, HA Astaro Secondary 5 NICs (Internal, WAN, DMZ, Wireless Bridge, HA) 2 VMs on Internal 2 VMs on DMZ  The HA is linked directly over a crossover cable between the two servers.  So here is the problem.  The servers on the DMZ on Server 2 cannot be reached.  No matter what changes I make to my config I cannot reach these servers.  Well I can if I log into the DMZ server on Server 1 I can reach the other DMZ servers.  I cannot however reach them from outside/inside directly.  If I shut down my secondary HA node.  Then everything works just as it is designed.  But as long as that secondary is up then nothing works.  I am open to all suggestions here.  One idea I thought to try out was to put the secondary HA node on its own direct internal LAN link.  Where it gets its own virtual switch, the last available NIC on the server and link to the switch.  I don't see why that would be necessary but at this point I'm willing to try anything to get this working 100%.  Thank you all in advance for your help with this.



    Known Problem.
    You will find the solution here in one of the postings. 
    I had the same problems month ago.

    Ralf
  • btw: Some People have suggested that the Problem comes from the Virtual Switches which have an integrated Logic, which blocks outgoing/incoming Traffic if the Mac-Address is known on a VM on the same Switch. (not sure, it's a long time ago [:)] )


    It's the same as the logic governing regular switches. Regular switches learn which MAC's are on various ports and forward the traffic based on that, the whole intent of a switch vs hub. We want the switch to forward traffic only to the ports that MAC address is on. In the case of a cluster of UTM's with physical switch(es), the physical switch(es) learns the MAC is on two ports so forwards traffic to both ports. This is what makes the failover process seamless.

    In the case of the vSwitch, part of this process is short-circuited. The logic inside the switch sees the virtual MAC as belonging to the VM and assumes this 'port' of it's switch is the only instance of that MAC on this network. This causes all VM's to attempt to reach the local node of the cluster, and not the actual active node.

    When you disable the virtual MAC on the UTM cluster, the vSwitches now see different MAC's for each node, see that the active node is not the same MAC as the local node, and forward packets out of the vSwitch onto the regular network.
  • Thank you all for the tips with this.  I have this working properly now.  Thanks