Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 3 subscribers
  • Views 2015 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

Can't reach servers when secondary node is alive

thefuzz4
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.
Parents
  • 0
    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 [:)] )
Reply
  • 0
    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 [:)] )
Children
  • 0 in reply to solae
    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.