Re: [pfSense Support] haproxy
On Wed, Aug 4, 2010 at 7:39 AM, Hiren Joshi wrote: > Hi, > > I'm running a master/slave setup of 1.2.3 and about to install haproxy, > I have 2 options under packages: > BETA-0.29 > and > BETA-0.30 > > My question, why is the newer one marked as "stable"? > As we were doing some work on the package for a customer, we created yet another version for a reason that escapes me at the moment. Either of the non -dev ones should be fine. We need to get that back down to two (at most, not sure -dev is needed anymore either), I'm checking on which of those should still be around. - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] multi-wan, multi-lan security
On Thu, Aug 5, 2010 at 9:20 PM, Chris Buechler wrote: > it's a simple fat finger to drop that traffic into your LAN. That's poetry. db - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] multi-wan, multi-lan security
On Thu, Aug 5, 2010 at 1:25 PM, Bao Ha wrote: > > Perhaps, Cisco is expecting a firewalled network to use managed > switches. Is it best practice? Why is there a resistance to VLAN in > the pfSense community? > I don't think anyone in this thread is expressing resistance to VLANs in general, not me at least. Every network that runs this project uses VLANs in some fashion. None of them combine unfiltered Internet traffic on the same switch as networks behind the firewall though. That's the only point I'm trying to get across here. If you're putting unfiltered Internet traffic on the same switch as your internal networks, it's a simple fat finger to drop that traffic into your LAN. It's much harder to plug something into the wrong place inadvertently, and if you do, it's not going to work as expected, where a VLAN misconfiguration could put a port into both the unfiltered Internet segment and the LAN segment, so you may not notice. > I had somebody asked about at least ten port pfSense router with > ability adding more as needed. He wants to provide Internet to a > building but wants each tenant to be on a separate network. I asked > why doesn't he just use a managed switch and trunk everybody to the > router? > That's a good solution, exactly what we've done a number of times for similar scenarios, there are production setups like that running more than 100 VLANs on a box (and I did a proof of concept with 4000 VLANs assigned. you'll want 2.0 for 100+, 1.2.x is way too slow in processing interfaces). Everyone in their own VLAN, so if they're infected by some ARP poisoning tool, or plug their router in backwards adding a rogue DHCP server, etc. they can't impact anyone else. Depending on your switches there are other options like PVLANs, DHCP snooping, etc. Generally with lower end managed switches your only option is one VLAN per port, and that works fine. - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] iPad ssl vpn client
If you jailbreak your ipad there is a openvpn client. On Thu, Aug 5, 2010 at 11:13 AM, Vick Khera wrote: > On Thu, Aug 5, 2010 at 4:28 AM, Seth Mos wrote: >> Viscosity on the Mac works great, but that doesn't apply to iOS. >> > > We just punt and use the PPTP client built-in to iOS. It is not > really as secure as we'd like but we normally only run ssh or an https > connection over it so that part is double secured. I'd *love* to see > an OpenVPN client. > > - > To unsubscribe, e-mail: support-unsubscr...@pfsense.com > For additional commands, e-mail: support-h...@pfsense.com > > Commercial support available - https://portal.pfsense.org > > - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] USB Keyboard - Boot Hangs
- "Tim Nelson" wrote: > - "Paul Mansfield" wrote: > > On 04/08/10 18:31, Tim Nelson wrote: > > > There is no option for legacy mode in the BIOS. :-( > > > > presumably there's no PS2 keyboard port? > > > > or if there is, your keyboard isn't the type which can turn into a > > ps2 > > keyboard using the oversized purple usb-to-ps2 plug thing that some > > come > > with? > > > > I have a ps2 KVM and a device which is usb only and I use one of > > these: > > http://tinyurl.com/35m36nc > > > > I've actually tried using an adapter that appears to be identical to > the one you reference with the same result. > > Unfortunately, this board does not have any PS2 ports, only USB. An interested thread about keyboard detection regression can be found here: http://old.nabble.com/ukbd-probe-order-regression-td27433764.html The situation is exactly the same as mine, a host with no PS2 ports, USB keyboard, same behavior. Is it possible for someone with better FreeBSD fu than I to apply the patch/recompile ukbd.c for testing? --Tim - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] new problem for me
On Thu, Aug 5, 2010 at 7:35 AM, Tiago wrote: > > > Hello guys > > I use pfsense 1.2.3 and everything is ok... > > But there is a user in my network that use a msn messenger on the browser... > > I tried to stop this using DNS Forwarder but the site changes every > day...The website is > > X10.iloveim.com > X11.iloveim.com > X30.iloveim.com > > Etc... > > The number after X can be between 1 and 999 > > How to solve this using DNS Forwarder??? > Use a domain override for iloveim.com to send it to an IP that won't respond. - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
RE: [pfSense Support] multi-wan, multi-lan security
> The low-end Cisco ASA 5505 requires VLAN configuration since it is > just a switch. > The Cisco ASA 5510 has four Ethernet ports. If you need more, just > use VLAN. > Perhaps, Cisco is expecting a firewalled network to use managed > switches. Is it best practice? Why is there a resistance to VLAN in > the pfSense community? You'll note that the *switch* vendors are generally the ones pushing VLANs on firewalls: I don't think this is a coincidence. Of course, every major firewall vendor does support VLANs now, and most also support LAGs, because many people do use them. I wouldn't say I put up any "resistance" to VLANs, nor anything I've seen in this thread. It's just that experience has shown many of us (me, anyway) that implementing VLANs adds another layer of complexity. VLAN-on-LAG adds another layer on top of that. Every additional layer we have to work with increases the possibility of making errors. (In my experience, the occurrence of errors roughly doubles with each layer added.) And in what is usually the most secure device on the network - the firewall - you don't want to make errors. Especially when, more often than not, the firewall is the *only* secure device on the network! As I indicated in my post, using VLANs allows for new and (*cough*) interesting failure modes that you just don't have to deal with otherwise. Note that I do use VLANs and will continue to do so. The largest network I've designed (for a regional ISP) trunks over 100 different VLANs back to the core, and there's a Cisco 7206 with >100 subifs managing it all quite happily, even their two upstream pipes are trunked in on VLANs, and "internal" and "external" networks share the same wire in many places, separated only by tags. Most of my firewall deployments do use VLANs; one must be much more careful when doing so. I have encountered (and caused!) problems that would not have occurred in a non-VLAN environment. So if you don't *need* VLANs, don't use them. If you *need* VLANs, go ahead and use them. Just like any other technology. > I sold a Cisco Catalyst 3500XL with 48 Fast Ethernet ports for $35 > a couple of months ago on eBay. I don't think cost is the issue. I agree. Chris also pointed this out a few posts ago. Although it could be argued that GigE "smart" switches still aren't negligibly cheap: I think the cheapest one I can get in Canada is around $300. Still not very expensive, especially compared to the firewall hardware I'd need to actually route data at over 100Mbps. -Adam - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] multi-wan, multi-lan security
Just want to throw another data point into this confusing discussion. The low-end Cisco ASA 5505 requires VLAN configuration since it is just a switch. The Cisco ASA 5510 has four Ethernet ports. If you need more, just use VLAN. Perhaps, Cisco is expecting a firewalled network to use managed switches. Is it best practice? Why is there a resistance to VLAN in the pfSense community? I had somebody asked about at least ten port pfSense router with ability adding more as needed. He wants to provide Internet to a building but wants each tenant to be on a separate network. I asked why doesn't he just use a managed switch and trunk everybody to the router? I sold a Cisco Catalyst 3500XL with 48 Fast Ethernet ports for $35 a couple of months ago on eBay. I don't think cost is the issue. Bao On Thu, Aug 5, 2010 at 10:08 AM, Adam Thompson wrote: > Comments from another perspective on the must/should question: > > Best practice says to physically segregate networks by trust level and by > impact of error or breach. > > Somewhat self-evidently, this is to mitigate the impact of a) errors, and > b) security breaches. Of the two, errors (i.e. human errors) are by far > the more common problem. > > If you have a separate NIC for each network coming in to your firewall, > the cables are well-identified, the ports are well-identified, and the > other endpoint of those cables is also well-identified, it's much harder > to accidentally expose high-trust traffic to a low-trust network. > Specifically, it's far likelier that someone will notice that the cable > they're holding has an "AT&T" tag on it but the port they're about to plug > it into has a "PacBell" label over it. > > When you use a switch and VLANs to segregate traffic, you have to worry > about things like: in a pathological power situation (lightning strike, > UPS blows up, whatever) if the switch is suddenly reset to factory > defaults - and I've seen this happen - what will happen? Every port gets > reset to VLAN 1 with no filtering, and all your traffic is suddenly being > propagated to every network segment. > > Maybe you're thinking "big deal", but now consider the fairly-typical WAN > situation where you're running routing protocols across WAN links, say > RIPv2 without authentication (because you trust all the networks involved, > right? It's a point-to-point link, right?). Your network topology > suddenly collapses and takes [fixing or unplugging]+2hrs to reconverge. > > Or the situation I once found: two smallish WAN providers both (stupidly) > left STP turned on at the edge... when they were suddenly bridged together > (by accident, I made a typo when setting up the VLANs) I managed to take > down most of both providers' networks, and typical of STP both were down > for +5 minutes. Obviously I > wasn't happy, and when we all figured out what had happened they weren't > very happy with me, either. > > As to security breaches, it is extremely difficult to a) know about the > switch, b) target the switch, and c) hack the switch, but it's > *infinitely* harder to hack a piece of Cat5 cable than a switch! > > Having said all that, many of the firewall modules/blades you can buy for > chassis-based routers and switches (Cisco 3600 ISR, Catalyst 1, > Juniper [something], etc.) require you to configure their ports entirely > using VLANs anyway. > > So it's hardly a universal "must", certainly not in the technical sense - > it's a very, very strong "should" that you should only disregard if a) > you're overconfident of your own abilities, b) you have no truly private > data, c) you don't care too much about pissing off your WAN providers (or > you know they won't even notice!), and d) you don't have enough space to > mount one or two more switches in the server closet. > > Note also that you might be tempted to use 802.1q-over-802.3ad > (VLAN-over-LAG), which does work... but also generally speaking turns off > a lot of the hardware acceleration your NIC can do for you. Many NICs > (certainly any half-decent one!) can still do IP offload with 802.1q (VLAN > tagging), but I haven't run into any that can still do IP offload with > 802.3ad (link aggregation, aka "bonding", or "etherchannel"). Bundling > links together (LAG) actually slowed my router down instead of speeding it > up. > > Another aspect is that if you're going to run your router in a blade > chassis, say, (virtualized or not) you really won't have much choice but > to use VLANs for everything - most blade chassis don't give you dedicated > physical Ethernet ports, certainly not more than two on any I've seen. > Most of 'em have an embedded NIC (or two, or four...) that plug straight > into a backplane and are only exposed via a switch module. > > (I am also noticing that pfSense 1.2.3 does not have good performance (for > me, at least) forwarding traffic between "virtual switches" on a VMWare > ESXi 4 host connected to the switch through a 4x V-in-LAG trunk. I > haven't had time t
Re: [pfSense Support] PFSENSE 2.0
On Aug 5, 2010, at 5:20 PM, David Burgess wrote: > On Thu, Aug 5, 2010 at 9:09 AM, Johan Hendriks > wrote: > >>> does freeBSD support trim with SSDs? > >> as of Freebsd 8.1 it is. >> >> read the following: >> http://www.freebsd.org/releases/8.1R/relnotes-detailed.html#DISKS > > Very interesting. I see this in the latest build log for 2.0: > > Thu Aug 5 03:00:22 EDT 2010 -|- pfSense version: 8 > Thu Aug 5 03:00:22 EDT 2010 -|- FreeBSD branch: RELENG_8_1 > > So does that mean we're on version 8 or 8.1? I'm about to move to an > SSD install with squid and trim would be nice. > > db > 8.1-RELEASE(+Patches and security things). releng_8 would be 8-stable, which will be 8.2, 8.3 etc. Cheers Remko -- /"\ Best regards,| re...@freebsd.org \ / Remko Lodder | re...@efnet Xhttp://www.evilcoder.org/| / \ ASCII Ribbon Campaign| Against HTML Mail and News - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
RE: [pfSense Support] multi-wan, multi-lan security
Comments from another perspective on the must/should question: Best practice says to physically segregate networks by trust level and by impact of error or breach. Somewhat self-evidently, this is to mitigate the impact of a) errors, and b) security breaches. Of the two, errors (i.e. human errors) are by far the more common problem. If you have a separate NIC for each network coming in to your firewall, the cables are well-identified, the ports are well-identified, and the other endpoint of those cables is also well-identified, it's much harder to accidentally expose high-trust traffic to a low-trust network. Specifically, it's far likelier that someone will notice that the cable they're holding has an "AT&T" tag on it but the port they're about to plug it into has a "PacBell" label over it. When you use a switch and VLANs to segregate traffic, you have to worry about things like: in a pathological power situation (lightning strike, UPS blows up, whatever) if the switch is suddenly reset to factory defaults - and I've seen this happen - what will happen? Every port gets reset to VLAN 1 with no filtering, and all your traffic is suddenly being propagated to every network segment. Maybe you're thinking "big deal", but now consider the fairly-typical WAN situation where you're running routing protocols across WAN links, say RIPv2 without authentication (because you trust all the networks involved, right? It's a point-to-point link, right?). Your network topology suddenly collapses and takes [fixing or unplugging]+2hrs to reconverge. Or the situation I once found: two smallish WAN providers both (stupidly) left STP turned on at the edge... when they were suddenly bridged together (by accident, I made a typo when setting up the VLANs) I managed to take down most of both providers' networks, and typical of STP both were down for +5 minutes. Obviously I wasn't happy, and when we all figured out what had happened they weren't very happy with me, either. As to security breaches, it is extremely difficult to a) know about the switch, b) target the switch, and c) hack the switch, but it's *infinitely* harder to hack a piece of Cat5 cable than a switch! Having said all that, many of the firewall modules/blades you can buy for chassis-based routers and switches (Cisco 3600 ISR, Catalyst 1, Juniper [something], etc.) require you to configure their ports entirely using VLANs anyway. So it's hardly a universal "must", certainly not in the technical sense - it's a very, very strong "should" that you should only disregard if a) you're overconfident of your own abilities, b) you have no truly private data, c) you don't care too much about pissing off your WAN providers (or you know they won't even notice!), and d) you don't have enough space to mount one or two more switches in the server closet. Note also that you might be tempted to use 802.1q-over-802.3ad (VLAN-over-LAG), which does work... but also generally speaking turns off a lot of the hardware acceleration your NIC can do for you. Many NICs (certainly any half-decent one!) can still do IP offload with 802.1q (VLAN tagging), but I haven't run into any that can still do IP offload with 802.3ad (link aggregation, aka "bonding", or "etherchannel"). Bundling links together (LAG) actually slowed my router down instead of speeding it up. Another aspect is that if you're going to run your router in a blade chassis, say, (virtualized or not) you really won't have much choice but to use VLANs for everything - most blade chassis don't give you dedicated physical Ethernet ports, certainly not more than two on any I've seen. Most of 'em have an embedded NIC (or two, or four...) that plug straight into a backplane and are only exposed via a switch module. (I am also noticing that pfSense 1.2.3 does not have good performance (for me, at least) forwarding traffic between "virtual switches" on a VMWare ESXi 4 host connected to the switch through a 4x V-in-LAG trunk. I haven't had time to isolate the problem yet, although I observed slightly better performance when I let VMWare handle the VLAN tagging instead of pfSense (i.e. created 4 untagged virtual e1000 NICs instead of 1 tagged vnic). Performance only seems affected if either ingress or egress traffic is local to the ESXi host, I see more-or-less normal performance if both src and dst are off-host.) -Adam Thompson athom...@athompso.net - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] multi-wan, multi-lan security
On 8/5/10 8:13 AM, David Burgess wrote: > Paul, > > I understand your post up to this point: > >> if the switch's port are set so that connected devices can't cause them >> to flip from untagged to tagged mode (in cisco speak from access to >> trunk - "switchport nonegotiate" > > I'm looking at the help file for my switch, and thinking this section > is saying what you're saying: > > "Ingress Filtering - When enabled, the frame is discarded if this port > is not a member of the VLAN with which this frame is associated. In a > tagged frame, the VLAN is identified by the VLAN ID in the tag. In an > untagged frame, the VLAN is the Port VLAN ID specified for the port > that received this frame. When disabled, all frames are forwarded in > accordance with the 802.1Q VLAN bridge specification. The factory > default is disabled." The "switchport nonegotiate" command has a different meaning in the context of Cisco Catalyst switches: It disables the use of Dynamic Trunking Protocol, a proprietary means of determining whether two switches will use trunking (tagged frames) to carry traffic between them. There may be exceptions, but DTP generally won't work between a Cisco and a non-Cisco device, or between two non-Cisco devices. Here's an sample reference from the Catlyst 3560 docs: http://is.gd/e4mFq dn - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] PFSENSE 2.0
On Thu, Aug 5, 2010 at 9:09 AM, Johan Hendriks wrote: >> does freeBSD support trim with SSDs? > as of Freebsd 8.1 it is. > > read the following: > http://www.freebsd.org/releases/8.1R/relnotes-detailed.html#DISKS Very interesting. I see this in the latest build log for 2.0: Thu Aug 5 03:00:22 EDT 2010 -|- pfSense version: 8 Thu Aug 5 03:00:22 EDT 2010 -|- FreeBSD branch: RELENG_8_1 So does that mean we're on version 8 or 8.1? I'm about to move to an SSD install with squid and trim would be nice. db - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] multi-wan, multi-lan security
Paul, I understand your post up to this point: > if the switch's port are set so that connected devices can't cause them > to flip from untagged to tagged mode (in cisco speak from access to > trunk - "switchport nonegotiate" I'm looking at the help file for my switch, and thinking this section is saying what you're saying: "Ingress Filtering - When enabled, the frame is discarded if this port is not a member of the VLAN with which this frame is associated. In a tagged frame, the VLAN is identified by the VLAN ID in the tag. In an untagged frame, the VLAN is the Port VLAN ID specified for the port that received this frame. When disabled, all frames are forwarded in accordance with the 802.1Q VLAN bridge specification. The factory default is disabled." Would you agree that Ingress Filtering on this switch appears to be the feature that you're describing? > but even so I still really want to physically isolate unfirewalled > network strands just in case! Point taken, from you and Chris as well. I should be able to get my hands on a used Cisco 3550 in the next few months to accomplish this. In the mean time I'm going to use this opportunity to learn the functions of my switch and improve my security practices. At this point I trust the small number of users on my OPT interfaces, however that will change. Thanks for the feedback. db - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] iPad ssl vpn client
On Thu, Aug 5, 2010 at 4:28 AM, Seth Mos wrote: > Viscosity on the Mac works great, but that doesn't apply to iOS. > We just punt and use the PPTP client built-in to iOS. It is not really as secure as we'd like but we normally only run ssh or an https connection over it so that part is double secured. I'd *love* to see an OpenVPN client. - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] PFSENSE 2.0
Op 5-8-2010 16:44, Paul Mansfield schreef: On 05/08/10 07:53, Seth Mos wrote: Do note, that if you ever write the device from start to end that this negates the wear levelling. It then only has the spare cells on the drive or card to remap blocks (~7%). does freeBSD support trim with SSDs? - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org as of Freebsd 8.1 it is. read the following: http://www.freebsd.org/releases/8.1R/relnotes-detailed.html#DISKS regards, -- ___ Johan Hendriks Schavemaker Transport Tel: +31 (0)251 229098 Fax: +31 (0)251 212016 email: j.hendr...@schavemaker.com web: http://www.schavemaker.com ___ Confidentiality Notice: The information in this document may be confidential. It is intended only for the use of the named recipient. If you are not the intended recipient, please notify me immediately and then delete this document. Do not disclose the contents of this document to any other person, nor take any copies. Violation of this notice may be unlawful. ___ - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] PFSENSE 2.0
On 05/08/10 07:53, Seth Mos wrote: > Do note, that if you ever write the device from start to end that this > negates the wear levelling. It then only has the spare cells on the > drive or card to remap blocks (~7%). does freeBSD support trim with SSDs? - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] multi-wan, multi-lan security
On 05/08/10 06:51, David Burgess wrote: > my DSL and LAN ports will be on the same switch, different vlans. This ... > what are my risks? I know it has been said on this list that WAN and if you can clearly label the switch so that you yourself "cannot" make a mistake when connecting cables if you use colour-coded cables to prevent accidental cable swapping if the switch is physically secure requiring a key if the switch has no IP address on untrusted/dangerous vlans if the switch has access controls to limit access to management port to trusted networks, and has username/password authentication (preferably over ssh or https) if the switch's port are set so that connected devices can't cause them to flip from untagged to tagged mode (in cisco speak from access to trunk - "switchport nonegotiate" then I'd say it's fairly safe. but even so I still really want to physically isolate unfirewalled network strands just in case! - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
[pfSense Support] new problem for me
Hello guys I use pfsense 1.2.3 and everything is ok... But there is a user in my network that use a msn messenger on the browser... I tried to stop this using DNS Forwarder but the site changes every day...The website is X10.iloveim.com X11.iloveim.com X30.iloveim.com Etc... The number after X can be between 1 and 999 How to solve this using DNS Forwarder??? Thanks in advance - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
[pfSense Support] iPad ssl vpn client
Hello, Just inquiring here, does anybody already know of a SSL vpn client that works on the Apple iPad devices? Viscosity on the Mac works great, but that doesn't apply to iOS. I see mentions of a Cisco and Juniper client, but no idea if these can be made to work with pfSense. Regards, Seth - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] multi-wan, multi-lan security
On Thu, Aug 5, 2010 at 2:08 AM, Tortise wrote:
> - Original Message - From: "Chris Buechler"
> To:
> Sent: Thursday, August 05, 2010 6:01 PM
> Subject: Re: [pfSense Support] multi-wan, multi-lan security
>
>
>> Doing VLANs properly all on one switch is probably pretty safe if done
>> right (biggest risk in those kind of setups is accidental
>> misconfiguration). I wouldn't do it though, managed switches are too
>> cheap to not physically segment your internal and external networks.
>>
>
> Hi Chris,
>
> Do you mind if I ask you re-express the last sentence please, ("I wouldn't
> do it though, managed switches are too cheap to not physically segment your
> internal and external networks. ") I am having trouble gleaning what I think
> is your intended meaning. Too cheap doesn't seem an adequate justification
> in itself, if that is what you intend?
>
It's best to physically segregate networks of considerably different
trust levels. Especially unfiltered Internet traffic and your internal
network - I would never setup a network like that. To answer an
initial question posed: " At what point does 'should' become
'must'?" I would say it's never "should", always "must".
That option shouldn't be discarded because it's "not in the budget".
If you have the budget for 8 DSL lines, you can afford a switch. I
would do two switches even so you have some switch redundancy, 4
connections on each of two switches (we did a config exactly like that
for a customer in the past week, one of many), where you have adequate
ports on the firewall. Additional ports configured on each so if one
fails, you can physically move the ports and be back up and running on
them all again within minutes. That would cost considerably less than
just one month of 8 DSL lines, and you have a network that you should
feel much better about.
-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com
Commercial support available - https://portal.pfsense.org
