Re: [pfSense Support] multi-wan, multi-lan security
On 10/08/10 03:32, Chris Buechler wrote: if your provider provides ipv6 as well as ipv4 and devices on your lan are also ipv6, then you're more likely to have a major security breach?? has IPv6, you can end up with a public IPv6 address either via stateless autoconfiguration or DHCPv6 and be completely open on the IPv6 Internet (assuming no host firewall). so if you're an attacker and you've compromised a box, it's definitely worth checking for ipv6 connectivity since there's a fair chance its not firewalled off. - 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
it's definitely worth checking for ipv6 connectivity since there's a fair chance its not firewalled off. I disagree with this statement. What makes you believe this? Windows has had built-in, default firewalling for quite some time, as has almost every desktop distribution of linux. SOHO firewalls that don't firewall IPv6 don't do so because they're generally not IPv6 capable (see PFSense for an example of default-deny IPv6 when $supported=0). Most ISPs drop the most vulnerable Windows ports at their border and often even at the CPE, agnostic of addressing protocol. Nathan Eisenberg - 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
I disagree with this statement. What makes you believe this? Windows has had built-in, default firewalling for quite some time, as has almost every desktop distribution of linux. SOHO firewalls that don't firewall IPv6 don't do so because they're generally not IPv6 capable (see PFSense for an example of default-deny IPv6 when $supported=0). Most ISPs drop the most vulnerable Windows ports at their border and often even at the CPE, agnostic of addressing protocol. This is again, assuming that security is in place... when looking at security at the perimeter, we must assume there is NO security in place. (and adjust for it) Is it possible someone disabled the firewall on windows? Absolutely! , linux? Yes again! We can go back and forth on this Ifs, but assuming the worse, and preparing for it - is the best (and only) solution. - 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
This is again, assuming that security is in place... when looking at security at the perimeter, we must assume there is NO security in place. (and adjust for it) Is it possible someone disabled the firewall on windows? Absolutely! , linux? Yes again! We can go back and forth on this Ifs, but assuming the worse, and preparing for it - is the best (and only) solution. Tim, You're missing the point - I'm hardly assuming security is in place. What I objected to was the claim that there will be many V4 hosts with good and working firewalls, who will not be protected if addressed by V6. Will there be a few home users who have a mangled network at layer 1 and get screwed by autoconfiguration? Sure. Is there going to be an epidemic of hosts that have a V4 firewall, but no V6 firewall AND V6 addressability? Absolutely not. This is a non-issue, and not a very interesting one at that. Nathan Eisenberg - 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
thinking aloud... if your provider provides ipv6 as well as ipv4 and devices on your lan are also ipv6, then you're more likely to have a major security breach?? - 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
thinking aloud... if your provider provides ipv6 as well as ipv4 and devices on your lan are also ipv6, then you're more likely to have a major security breach?? It's only really thinking out loud if you including your reasoning, otherwise it's more like 'concluding out loud'. Why do you think that? Nathan Eisenberg - 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 09/08/10 17:57, Nathan Eisenberg wrote: thinking aloud... if your provider provides ipv6 as well as ipv4 and devices on your lan are also ipv6, then you're more likely to have a major security breach?? It's only really thinking out loud if you including your reasoning, otherwise it's more like 'concluding out loud'. Why do you think that? people won't be using NAT in an ipv6 network, so they'll have real IPs which will contain their MAC addresses, making it much more likely that the internet at large will be able to connect to them. - 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: Re: [pfSense Support] multi-wan, multi-lan security
On Mon, 2010-08-09 at 18:06 +0100, Paul Mansfield wrote: if your provider provides ipv6 as well as ipv4 and devices on your lan are also ipv6, then you're more likely to have a major security breach?? people won't be using NAT in an ipv6 network, so they'll have real IPs which will contain their MAC addresses, making it much more likely that the internet at large will be able to connect to them. The MAC address is only 48 bits out of 128, leaving 80 bits of assigned address in comparison to IPv4's 64 assigned bits. How is stumbling across a (nominally) random 80-bit address easier than stumbling across a (nominally) random 64-bit address? Obviously neither case is truly random, and I would argue that at this stage, IPv4 address allocation is more predictable than IPv6 address allocation. Finding either is bound to be easier than finding a truly random number, as there are many real-world constraints, but I believe there are more constraints on the 64-bit number than the 80-bit number, which would skew the model towards being even easier to find the IPv4 address... -Adam Thompson Chief Architect, C3A Inc. athom...@c3a.camailto:athom...@c3a.ca Tel: (204) 272-9628 x8004 / Fax: (204) 272-8291 attachment: winmail.dat- 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
people won't be using NAT in an ipv6 network, so they'll have real IPs which will contain their MAC addresses, making it much more likely that the internet at large will be able to connect to them. I still don't follow. NAT is not a security mechanism, and MAC addresses are not privileged information. If you're suggesting that more people will be connecting to the internet without a firewall, then I beg to differ (though pfsense doesn't support v6 yet, and just blocks ipv6 by default). Adam - While that's certainly true, in my opinion, whether an IP is known or unknown is irrelevant to that host's security. Best Regards, Nathan Eisenberg - 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
I still don't follow. NAT is not a security mechanism, and MAC addresses are not privileged information. True, but once you know the MAC you can find out the vendor quite easily, and then go about running exploits specific to that piece of hardware. Adam - While that's certainly true, in my opinion, whether an IP is known or unknown is irrelevant to that host's security. Again true, but i would change whether an IP is known or unknown IS irrelevant to whether an IP is known or unknown SHOULD BE irrelevant - the truth is, it's not though... For the most part we are talking mainstream people here... and while if a piece of hardware has been bullet tested (security wise) by a professional - a public address/mac shouldn't effect it, as the security measures are in place... to an untrained person with no or little security in place, every piece of information that is accessible is more fuel used to attach the host. You can fight either way, but the truth is , the more information you can keep secret - the better, this whole thread can be summed up with that... -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] multi-wan, multi-lan security
On Mon, Aug 9, 2010 at 12:07 PM, Paul Mansfield it-admin-pfse...@taptu.com wrote: thinking aloud... if your provider provides ipv6 as well as ipv4 and devices on your lan are also ipv6, then you're more likely to have a major security breach?? I was thinking of that scenario earlier in the thread but didn't mention it, if you happen to combine your LAN and WAN at L2, your internal hosts have IPv6 enabled (as most new OSes do), and your ISP has IPv6, you can end up with a public IPv6 address either via stateless autoconfiguration or DHCPv6 and be completely open on the IPv6 Internet (assuming no host firewall). Granted the chances of getting attacked via v6 on a random address are very, very slim because there are too many IPs to scan the entire IPv6 Internet in a reasonable amount of time (until someone builds a large IPv6-connected botnet). My guess is you could take a machine full of security holes (old Linux distro at defaults, unpatched Windows XP, etc.), leave it wide open to the Internet on IPv6 only, and it probably wouldn't get touched for a year or more where it'd be owned in hours if not minutes open on IPv4. A more likely scenario to be opened to the Internet and not realize it, yes possibly. But highly unlikely to be attacked, at random at least, in such a scenario. - 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
That's poetry. It might be, if it were true. I'm not sure that it is, though. From a distribution layer (/30 for routing to a firewall from a router), I can't think of what you'd need to intentionally do to allow bypass of the firewall that has anything to do with VLANs. If I somehow moved the router into one of the 'internal' networks, bypassing the firewall, the router would have no route to a host, nor would the host have a route to the router. The only exception would be if you're running a L2 bridging firewall, but then I don't think the concept of VLANs is even applicable... Explain? Best Regards, Nathan Eisenberg
Re: [pfSense Support] multi-wan, multi-lan security
On Fri, Aug 6, 2010 at 7:40 PM, Nathan Eisenberg nat...@atlasnetworks.us wrote: That's poetry. It might be, if it were true. I'm not sure that it is, though. From a distribution layer (/30 for routing to a firewall from a router), I can't think of what you'd need to intentionally do to allow bypass of the firewall that has anything to do with VLANs. If I somehow moved the router into one of the 'internal' networks, bypassing the firewall, the router would have no route to a host, nor would the host have a route to the router. The only exception would be if you're running a L2 bridging firewall, but then I don't think the concept of VLANs is even applicable... You're missing the entire point. If you have one switch, VLAN 2 is your LAN, and VLAN 3 is your unfiltered Internet, and you put both 2 and 3 untagged on the same port... there ya go. From there the amount of damage possible and ease of it happening depends on what kind of Internet connection you have. - 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
You're missing the entire point. If you have one switch, VLAN 2 is your LAN, and VLAN 3 is your unfiltered Internet, and you put both 2 and 3 untagged on the same port... there ya go. From there the amount of damage possible and ease of it happening depends on what kind of Internet connection you have. You lose me right where you say ... there ya go. How do you propose to get your malicious traffic to my vulnerable host? Yes, it's now on the same layer 2 domain - but I'm not sure how that can be exploited by an external attacker. Think of it this way, if you'll accept an analogy: I have a router that passes 1.1.1.0/30 to my firewall's WAN port. 1.1.2.0/24 is routed to that IP, so my LAN interface is 1.1.2.1, and I have a host at 1.1.2.2. I remove the firewall from the equation and plug my router straight into my LAN's physical network. Find a way to ping 1.1.2.2. You can't. My network is, for all external intents and purposes, down. My hosts can't route out. You can't route in, because my router's sending packets to 1.1.1.1, which is down. Your attack is thwarted by the way that layer 3 works. Say I'm not being routed a /24. Say I'm on Comcast and I have a 192.168.0.0/24 LAN. The problem is now even bigger: your carrier, their carrier, and Comcast won't route 192.168.0.0/24. What I'm trying to point out is that there is a difference between real and false security. I don't see a clear, enumerable threat, or any conditions that I, an attacker, could use to break in. There's a lot of real security work to do; work that can be explained in terms of technically possible/probable vectors. Whenever someone says this makes you more secure, I like to ask Is that true? And if so, what makes it true?. So, what makes your claim, that using VLANs on the same switching fabric for both interfaces of a firewall allows the network the firewall protects to be exploited, true? Best Regards, Nathan Eisenberg - 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 Fri, Aug 6, 2010 at 8:50 PM, Nathan Eisenberg nat...@atlasnetworks.us wrote: You're missing the entire point. If you have one switch, VLAN 2 is your LAN, and VLAN 3 is your unfiltered Internet, and you put both 2 and 3 untagged on the same port... there ya go. From there the amount of damage possible and ease of it happening depends on what kind of Internet connection you have. You lose me right where you say ... there ya go. How do you propose to get your malicious traffic to my vulnerable host? Yes, it's now on the same layer 2 domain - but I'm not sure how that can be exploited by an external attacker. That's my last point - depends on your Internet connection. If it's DHCP or DHCP is available, you could be pulling a public IP from upstream and leaving a LAN host wide open outside the firewall. If you're on a connection type where WAN is a large broadcast domain like cable, a few thousand hosts will then start seeing your internal ARP and could ARP poison your LAN. There are other possibilities depending on your connection type. It's not worth the risk. With many commercial-grade connections there are less options there, and with some it would be virtually impossible to do anything where there's a router between your ISP and your firewall, but it's still not worth the risk. - 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
- Original Message - From: Nathan Eisenberg nat...@atlasnetworks.us To: support@pfsense.com Sent: Saturday, August 07, 2010 12:50 PM Subject: RE: [pfSense Support] multi-wan, multi-lan security Say I'm not being routed a /24. Say I'm on Comcast and I have a 192.168.0.0/24 LAN. The problem is now even bigger: your carrier, their carrier, and Comcast won't route 192.168.0.0/24. I think that is the theory however in practice I'm not so sure. It doesn't take much to, for example, accidentally connect a LAN to the net and suddenly...with some else doing the same...I think the private LAN becomes public and pretty sick pretty quickly also... Maybe Comcast can control for this but I doubt all ISP's do? My ISP advised us not use common private LAN addresses for this (common problem) reason. (I now use randomly generated addresses) - 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 Fri, Aug 6, 2010 at 9:37 PM, Tortise tort...@paradise.net.nz wrote: - Original Message - From: Nathan Eisenberg nat...@atlasnetworks.us To: support@pfsense.com Sent: Saturday, August 07, 2010 12:50 PM Subject: RE: [pfSense Support] multi-wan, multi-lan security Say I'm not being routed a /24. Say I'm on Comcast and I have a 192.168.0.0/24 LAN. The problem is now even bigger: your carrier, their carrier, and Comcast won't route 192.168.0.0/24. I think that is the theory however in practice I'm not so sure. It doesn't take much to, for example, accidentally connect a LAN to the net and suddenly...with some else doing the same...I think the private LAN becomes public and pretty sick pretty quickly also... Maybe Comcast can control for this but I doubt all ISP's do? My ISP advised us not use common private LAN addresses for this (common problem) reason. (I now use randomly generated addresses) There are good reasons to use uncommon subnets, primarily because it eases connecting with other networks without hacks like NAT, but that's not among them. What subnet you use internally has no relevance to your ISP. The risk isn't in the private subnet leaking out to WAN unless you're talking about the ARP poisoning possibility, or the fact if you do that on a medium like cable any of the thousands on your segment could easily join your LAN (even inadvertently if that also brings your internal DHCP server onto the ISP network, but that is likely to either be blocked by the ISP or get you cut off very quickly once it happens). An obscure subnet wouldn't matter in that scenario, everyone on the segment would see what your subnet is. - 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
- Original Message - From: Chris Buechler cbuech...@gmail.com To: support@pfsense.com Sent: Saturday, August 07, 2010 2:09 PM Subject: Re: [pfSense Support] multi-wan, multi-lan security On Fri, Aug 6, 2010 at 9:37 PM, Tortise tort...@paradise.net.nz wrote: - Original Message - From: Nathan Eisenberg nat...@atlasnetworks.us To: support@pfsense.com Sent: Saturday, August 07, 2010 12:50 PM Subject: RE: [pfSense Support] multi-wan, multi-lan security Say I'm not being routed a /24. Say I'm on Comcast and I have a 192.168.0.0/24 LAN. The problem is now even bigger: your carrier, their carrier, and Comcast won't route 192.168.0.0/24. I think that is the theory however in practice I'm not so sure. It doesn't take much to, for example, accidentally connect a LAN to the net and suddenly...with some else doing the same...I think the private LAN becomes public and pretty sick pretty quickly also... Maybe Comcast can control for this but I doubt all ISP's do? My ISP advised us not use common private LAN addresses for this (common problem) reason. (I now use randomly generated addresses) There are good reasons to use uncommon subnets, primarily because it eases connecting with other networks without hacks like NAT, but that's not among them. What subnet you use internally has no relevance to your ISP. The risk isn't in the private subnet leaking out to WAN unless you're talking about the ARP poisoning possibility, or the fact if you do that on a medium like cable any of the thousands on your segment could easily join your LAN (even inadvertently if that also brings your internal DHCP server onto the ISP network, but that is likely to either be blocked by the ISP or get you cut off very quickly once it happens). An obscure subnet wouldn't matter in that scenario, everyone on the segment would see what your subnet is. - Yes I was referring to ARP poisoning and my cable connection experience which is the reason for the random (obscure) LAN subnet range selection... It just seemed an example of a situation that was outside the example posed where it was suggested there was no risk, when there may be? - 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:51 AM, David Burgess apt@gmail.com wrote: I've been running the 2.0 betas for a few months and I'm quite happy with it. Some network and hardware upgrades present me with a few questions, and maybe I'm overthinking it, but I thought I would ask the opinion of the wise ones. I'm running mlppp and it works beautifully. For the last 2-3 months it's been just 2 DSL connections, so they each got a dedicated NIC on the net5501. Now I'm upsizing significantly to 8 DSL lines, and since there's no reasonable way of getting enough physical ports into the 5501, I'm obviously forced to use vlans to get all the DSL and LAN connections up. I have a single smart swith with vlan capability, but a second smart switch is not in the budget at the moment. A managed switch can be bought for very little. Bunch of HP 2512/2524s on ebay that go for $50 USD or less shipped, lot of similar others. In the scheme of things, compared to paying for 8 DSL lines, that's nothing. 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. - 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
- Original Message - From: Chris Buechler cbuech...@gmail.com To: support@pfsense.com 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? - 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 tort...@paradise.net.nz wrote: - Original Message - From: Chris Buechler cbuech...@gmail.com To: support@pfsense.com 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
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
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] 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] 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 ATT 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 time to figure out what I did and fix it+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
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 athom...@c3a.ca 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 ATT 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 time to figure out what I did and fix it+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
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
On Thu, Aug 5, 2010 at 1:25 PM, Bao Ha b...@hacom.net 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] multi-wan, multi-lan security
On Thu, Aug 5, 2010 at 9:20 PM, Chris Buechler cbuech...@gmail.com 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
[pfSense Support] multi-wan, multi-lan security
I've been running the 2.0 betas for a few months and I'm quite happy with it. Some network and hardware upgrades present me with a few questions, and maybe I'm overthinking it, but I thought I would ask the opinion of the wise ones. I'm running mlppp and it works beautifully. For the last 2-3 months it's been just 2 DSL connections, so they each got a dedicated NIC on the net5501. Now I'm upsizing significantly to 8 DSL lines, and since there's no reasonable way of getting enough physical ports into the 5501, I'm obviously forced to use vlans to get all the DSL and LAN connections up. I have a single smart swith with vlan capability, but a second smart switch is not in the budget at the moment. Therefore, my DSL and LAN ports will be on the same switch, different vlans. This brings me to my first question. 1. Given that -nobody but me has physical access to pfsense or its connected switch, -nobody outside my immediate family will have access to the management vlan of the switch, -nobody but me will have access to the web UI or console of pfsense, -WAN packets will be split across 8 DSL connections, what are my risks? I know it has been said on this list that WAN and LAN should be physically separated. At what point does 'should' become 'must'? Next, I have decided to replace the net5501 with a dual-Atom board (the Supermicro X7SPA of legend), which has 2 Intel GBE NICs*. Next question. 2. Given that -my WAN and LAN interfaces will coexist on a single switch, separated only by vlans, -my total throughput will be well below 1 gbps, -I have switch ports to spare, is there any advantage or disadvantage to using either one or both physical NICs on pfsense? Do I gain any security by running the mlppp member vlans on one physical NIC and the LAN/OPT vlans on the second physical NIC? Would I save any power by parenting all the vlans on a single physical NIC and leaving the other one (and another switch port) unplugged? Am I splitting hairs on this one? Thanks for your thoughts. I'm very grateful for the quality of the pfsense product, and for the unequalled body of expertise on this list. I considered posting this on a networking-specific forum, but I'm not convinced there is one quarter the talent hanging out there. db *I'm a little disappointed to retire the 5501 from firewall duty so soon. I chose it over other embedded hardware specifically for it's advantage in RAM and number of NICs, but my needs grew rapidly and before I ever really got to load it up I found myself needing more ports and faster storage. Ah well, I think it may still make a good monitoring tool and perhaps pbx and/or seedbox. - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
