[SOLVED] Unable To Reach Second pfSense Firewall On LAN
-
@postables said in Unable To Reach Second pfSense Firewall On LAN:
netgear-0[1,2] do not support it.
Are there any loops with those switches?
-
Mmm, those probably are not a problem if they each only have a single connection to one of the GS110s.
From your diagram it looks like you should have switch loops between both firewalls and the GS110s. Two loops on each side.
Steve
-
Yeah looks from his drawing to me that he has 2 lines coming up from those downstream.. You only need 1 loop and the whole thing can come down.. Especially with multiple carps - be a fair amount of multicast being sent out. And lots not forget the amount of broadcast and multicast even a single windows machine can put on the network..
Loops are Very Bad! We had a customer were they would have these idiot users that use to plug the phone in twice.. You know how you can bridge say a pc off a phone.. Well they would have a phone in a conference room and some user would get the smart idea that may it needs both connections plugged in ;)
Dumb switches really shouldn't be used in a work setup, other than maybe a few extra ports on some users desk because they are doing some special project or something.
-
@johnpoz said in Unable To Reach Second pfSense Firewall On LAN:
Dumb switches really shouldn't be used in a work setup, other than maybe a few extra ports on some users desk because they are doing some special project or something.
They still manage to create loops there.
Or they kick out the plug and the help desk phone rings.
LAYER 8
-
@johnpoz said in Unable To Reach Second pfSense Firewall On LAN:
Dumb switches really shouldn't be used in a work setup
I have a Cisco unmanaged switch that supports spanning tree.
-
Then I guess it's not a "dumb switch."
-
@Derelict said in Unable To Reach Second pfSense Firewall On LAN:
Then I guess it's not a "dumb switch."
It's certainly not managed. There's nothing to configure on it. Spanning tree is always on.
-
And what is the make and model of this switch? spanning tree without the ability to "configure" it not all that useful.
I just looked at specs for old sd2005 model and their 110 line - I don't see any spanning tree in the spec sheets.
-
@johnpoz said in Unable To Reach Second pfSense Firewall On LAN:
And what is the make and model of this switch? spanning tree without the ability to "configure" it not all that useful.
Geez. You made me go digging through my junk closet. Almost needed an archaeologist.
It appears I was thinking of another switch. This one is a Cisco SD216.
-
@JKnott said in Unable To Reach Second pfSense Firewall On LAN:
SD216.
That doesn't show any stp support per the spec sheets I can find.
-
@johnpoz said in Unable To Reach Second pfSense Firewall On LAN:
That doesn't show any stp support per the spec sheets I can find.
As I said in my previous post, I must have been thinking of another switch.
-
oh will that makes more sense - some smart/managed switch ;)
-
@johnpoz said in Unable To Reach Second pfSense Firewall On LAN:
spanning tree without the ability to "configure" it not all that useful.
Actually it is, for it's intended purpose of preventing loops. Spanning tree goes all the way back to 1985, which predates switches. Back then, bridges were used to extend coax based networks. There's not much that needs to be configured for basic spanning tree operation. Of course, with the managed switches used these days, things like priority and VLANs have to be configured, but those aren't necessary for a basic LAN.
-
We are talking modern networks ;)
So normally in a network where you would be using spanning tree - you would for sure want to be able to configure who the root bridge is, and yup priority, etc. etc..
So back to the OP network - if your going to be doing stuff where you need to leverage spanning tree to prevent loops... Then you need to make sure only smart/managed switches that support your level of spanning tree be it old school plain jane stp, or rstp or mstp or some proprietary stuff like pvst or vstp, etc. etc.. Or maybe you use SPB...
The thing is as a lan grows, quite often these sorts of design considerations are normally quite often overlooked until a problem presents itself. And hopefully the company brings in someone to help, or the staff actually knows how to do it or are fast learners ;) And just forgot about it because the lan grew organically and was never an issue, etc.
Pretty much every company have ever worked with the stp was either nonexistent or just whatever the switches default too.. And they have no idea why some switch in some odd ball closet somewhere in there ever growing lan is the root bridge ;)
-
I have also seen LANs where VLANs weren't properly configured. As for the root switch, that's the only one that has to be configured for priority, unless you like reading MAC addresses, to find the lowest one.
-
Let's agree correctly configured STP is a good thing and try and help the OP get things working shall we?
Steve
-
The horror stories are endless to be honest ;) Its some time amazing as you walk into a nice looking raised floor setup with nice hardware for everything... But come to find out when you look into things that stuff is just plugged in and nice cable management.. Nobody did anything when came to consideration of network actually be used to its full potential..
All concerned about failures - but then they have no redundancy, yeah that fancy $4k switch you got there but you forgo the 2nd power supply to save $200 bucks.. And sure you stack the switch nice, but hey your servers that you so worried about loss of connection that they have multiples, but are plugged into the same switch in the stack, and even the same port group on the same switch, etc..
edit: Just waiting on the OP.. There are no actual details to work with ;)
-
Will report back tonight with how the STP setup goes. Literally just finished replacing the unamanaged switches with managed ones and redid our cable wraps before I posted this. It definitely seems like it's an STP issue.
In the mean time I'm not sure if this is an additional symptom of the misconfigured switching network, or if this is due to an incorrect routing entry between both firewalls, which is making me unable to access both firewall webgui's at the same time remotely, but I can do it locally:
I have both pfsense firewalls installed, replicating xmlrpc and states between the two. Currently the ETH2 (LAN) port of the second firewall is connecting to the ETH6 (LAN) port of the first firewall. When I'm directly connected to the LAN via a switch, I can access the webgui for both the first, and second firewall.
However when I'm connected via VPN, I can only access the webgui for the firewall that I'm connected to via VPN. So if I open a VPN connection to the first firewall, I can access the webgui for the first firewall, but not the second. When I open a VPN connection to the second firewall, I can access the webgui for the second firewall, but not the first.
-
As far as I know, putting STP through the XG7100 (or any other non-STP switch) should work as long as there are enough STP-capable switches so enough ports are blocked to prevent loops. As long as you don't have a loop with non-STP switches it should be fine.
I have never set that up, however.
-
Another update: STP switching configs in place in all but the cisco switch since I'm a dumbass and forgot the credentials. Will be connecting the second firewall back to the switching network Monday and actually enabling the CARP setup, so hopefully the switching loop is resolved when I connect the second firewall back to the network. Thanks for the help so far all.
@Derelict said in Unable To Reach Second pfSense Firewall On LAN:
As far as I know, putting STP through the XG7100 (or any other non-STP switch) should work as long as there are enough STP-capable switches so enough ports are blocked to prevent loops. As long as you don't have a loop with non-STP switches it should be fine.
I have never set that up, however.
From my old networking days that sounds correct, but I as well haven't entirely tested that. Although I guess technically right now I am "testing it" given that 5/6 switches have STP configs, and 1 doesn't. Granted I haven't connected the second firewall back to the switching network, so there's no loops right now to test with.