> -----Original Message----- > From: Seth Mos > Sent: Monday, August 15, 2011 2:38 AM > To: [email protected] > Subject: Re: [pfSense Support] VPN Failover Backup > > Hi, > > I second that. Also, purchase "Designing Large Scale Networks" from O'reilly > from your favourite book store. > > I can recommend it highly to figure out what direction you want to venture > in, I've found it to be a great help. > > It handles L2 switching, aggregation and redundancy as well as all the routing > solutions. Since then I've implemented routing at work. pfSense being the > internal VLAN router. I'm using Dell R310 servers as the firewalls. > > Regards, > > Seth
Thanks for the suggestion, I'll have to add that to the list of books I'd like to pick up. > From: Chris Buechler > > Yeah that's the usual scenario for multiple buildings, you have one or several > IP subnets per building, with everything routed between. Then > accomplishing failover with a VPN and OSPF is pretty straight forward. > If it's all one big or several big broadcast domains across buildings, that's not > the best design and makes failover to VPN difficult to impossible to > accomplish regardless of what network equipment you're using. Aside from > other reasons you generally want to keep broadcast domains limited to one > physical location in such networks, like isolating layer 2 problems to a single > building, limiting broadcast traffic, etc. May need a pretty considerable > change to make VPN failover reasonable if everything is bridged together. I just logged into one of our switches to verify that we do have routes defined on the switches. While the wireless links are bridges, we do routing to keep spurious traffic from crossing the WAN links. I remember this now from when we first switched to the wireless links a couple years ago and retired the T1 lines. One of our concerns at first was if it was a bridge, did we have to redo all of the VLAN settings at each building since we would have multiple VLAN 1's, 2's, etc. But we saved ourselves from that by doing L3 routing on the core switches. > This sounds like the kind of scenario where you could benefit greatly from a > few hours of our time to go over your entire network design and implement > an appropriate solution. We have numerous customers in similar scenarios, > responsible for a thousand different things with minimal time to work on > such projects, and we can make your life a lot easier in that regard and save > you a bunch of time. Also an in-depth network review is generally beyond > what you'll be able to get thorough assistance with on a mailing list as it's time > consuming (and probably more than you want to publicly divulge). See > commercial support link in the footer for info. I would love to, but unless you give a friendly K-12 educational discount of free, I don't think it will happen. Our budget, while it hasn't shrank yet, it's not gone up in several years now either, so we're constantly trying to do more with less and I don't think this is something I would be able to convince my boss to do. I've wanted to get a wireless site survey done for a couple years now at our one building and that has never happened either, though I think I have done a pretty good job in placing our AP's through trial and error. So I'll most likely stick to trial and error testing with a few more posts to the mailing list. > From: David Miller [mailto:[email protected]] > > I may have spoken too quickly last time as what I said made a lot, probably > too may, assumptions about your network. So lets start over and say as with > most networking things "it depends". You've mentioned that the wireless > links are bridges but you also said that you believe that the switches are layer > 3 and may be used for routing. So the first thing you need to figure out is if > the traffic is being passed between buildings are just forwarded between > buildings using layer 2 mechanisms or is the traffic being routed by a router, > which may be a layer 3 switch in your case. We are routing across our L2 links. > So if you're dealing with a network that's routing traffic between the > buildings then my original reply stands. You should look at moving to a > dynamic routing solution such as OSPF. But based on some of your other > questions it sounds like this may not be the case. We are using static routes currently. Our core switches are Cisco 3750's performing basic core 3 routing based on destination. Basically something like this: ip route 10.20.0.0 255.255.0.0 10.250.250.20 ip route 10.30.0.0 255.255.0.0 10.250.250.30 ip route 10.40.0.0 255.255.0.0 10.250.250.40 ip route 10.222.20.0 255.255.255.0 10.250.250.20 ip route 10.222.30.0 255.255.255.0 10.250.250.30 ip route 10.222.40.0 255.255.255.0 10.250.250.40 The first 3 lines deal with regular network traffic and the last 3 deal with the VOIP VLAN, though all go to the same locations and I suppose we could of set up a subnet of something like 10.20.222.0 for VOIP so that we wouldn't need an extra rule, but I'm guessing it has something to do with QoS. > As for your dealing with QoS to work with VoIP goes. I don't see why you > wouldn't be able to do that but I don't know a lot about the QoS stuff in > pfSense other than it does support it so in theory you should be able to > prioritize the traffic as you need though pfSense. This is where a lot of my confusion comes from as well. I don't really know QoS at all. > Your question about VLANs is what tips me off that you're not routing > currently. But it's my understanding that a router will strip off the vlan tags. > So you would need to route traffic from one VLAN on network A to the > appropriate VLAN on network B where the frame will be tagged again. Yeah, that was me not completely thinking and having my brain take a mini-vacation. I knew we were doing routing, but for some reason was thinking the VLAN tags were still going through, though I should have known that to not be the case since we have 5 VLAN 1's, one at each location. One more question about OSPF routing, am I going to want to remove the routes from the switches or would it be beneficial to leave them in there, but point to the IP of the pfSense box and have it do OSPF routing to determine if it should go over the normal wireless links or over the VPN? I'm not sure, but I'd think that having the switches doing the basic routing to determine if it needs to go across a link would be more efficient and faster than passing that to the pfSense box and then back to the switch if it's only in a different subnet at the same building. Not sure how I'd incorporate QoS on the VOIP in this manner though, perhaps a virtual IP? Thank you all for your thoughts and I think I'm a bit closer to being ready to give this a test run once I get some spare time in a couple weeks. -- John McDonnell [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] Commercial support available - https://portal.pfsense.org
