[pfSense Support] pfSense + Squid ftp problem
Hi, We have setup the squid proxy package for LAN over a pfsense 1.2.3.-RELEASE* * where NO direct Internet access is allowed for users It works fine for the LAN users to access Internet / FTP through IE / Firefox with proxy enabled. The problem is that the LAN user cannot access any FTP server through FTP client such as Filezilla, CuteFTP, CoreFTP, with proxy enabled. ( Http / Site / User method /) The error from the client is that Access Denied. Squid Log shows: 1280931420.633 0 192.168.45.164 TCP_DENIED/403 1376 CONNECT ftp-internal.mydomain.int:21 - NONE/- text/html As the FTP access is possible through browser and we have no access control rules, what's the problem? The ftp client is configured to use generic proxy HTTP1.1 CONNECT method and Passive Mode Thanks and Regards, -- dpc
RES: [pfSense Support] new problem for me
Hi I tried to do it but didn't work I solved this using the blacklist on the proxy server adding the word iloveim.com Kind regards Tiago Picon DESENVOLVIMENTO Scenario - Automação Residencial (16) 3368-3399 - São Carlos tpi...@scenario.ind.br www.scenario.ind.br -Mensagem original- De: Chris Buechler [mailto:cbuech...@gmail.com] Enviada em: quinta-feira, 5 de agosto de 2010 16:28 Para: support@pfsense.com Assunto: Re: [pfSense Support] new problem for me On Thu, Aug 5, 2010 at 7:35 AM, Tiago tpi...@scenario.ind.br 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 - 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] haproxy
The stable one would not let me add a backend, it kept telling me that weight was mandatory even tho I was entering a number for it. The other one seems fine. Thanks, Josh. -Original Message- From: Chris Buechler [mailto:cbuech...@gmail.com] Sent: 06 August 2010 06:42 To: support@pfsense.com Subject: Re: [pfSense Support] haproxy On Wed, Aug 4, 2010 at 7:39 AM, Hiren Joshi j...@moonfruit.com 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 - 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
[pfSense Support] Re: multi-wan, multi-lan security
In message 24b7224eff7c4e19b1a43fd4df416...@dp2000xp Tortise tort...@paradise.net.nz was claimed to have wrote: My ISP advised us not use common private LAN addresses for this (common problem) reason. (I now use randomly generated addresses) I do hope you never need to contact the legitimate owner of whatever IPs you're using... Personally, if my provider gave me such advice (not just a single rep, but the provider's official policy) I'd find competent provider. - 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] Re: multi-wan, multi-lan security
In message 8c8f0f7add704cf491998cbe298fb...@dp2000xp Tortise tort...@paradise.net.nz was claimed to have wrote: 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's worth noting that even if you use an uncommon LAN subnet range selection internally, anyone in your broadcast domain could easily observe your ARP packets and find your IP range, so you're not gaining much security by obscurity here, although you are decreasing the odds that two random 192.168.0.0/24 networks will cross-talk if you both made the same configuration error at once. This assumes the case of a large ancient cable modem network that still broadcasts ARPs between client side networks on different modems, and assuming a configuration error directly connects a LAN to the WAN bypassing the firewall. In reality it's been a while since this was that big a deal on cable modem networks (or at least any that I've touched), around here it's probably been 5+ years since you could see floods of ARP requests. I think that the cable modems only transmit ARP requests from WAN to LAN for MAC addresses already known to exist on the LAN side, so strictly speaking your cable modem won't pass valid traffic after the modem is rebooted until the LAN side machine sends at least one packet up to the modem. This is a handy side effect of cable modems already needing to track valid MAC addresses to limit the number of machines connected for billing purposes. 10/8 is huge, 172.16/12 is a little less widely used and also significantly large enough that I've never ever personally seen any remote network overlapping with the /21 that I picked out for myself, and I VPN into remote client sides regularly, and travel somewhat frequently. - 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] Re: multi-wan, multi-lan security
- Original Message - From: Dave Warren dave-use...@djwcomputers.com To: support@pfsense.com Sent: Saturday, August 07, 2010 4:51 PM Subject: [pfSense Support] Re: multi-wan, multi-lan security In message 24b7224eff7c4e19b1a43fd4df416...@dp2000xp Tortise tort...@paradise.net.nz was claimed to have wrote: My ISP advised us not use common private LAN addresses for this (common problem) reason. (I now use randomly generated addresses) I do hope you never need to contact the legitimate owner of whatever IPs you're using... Personally, if my provider gave me such advice (not just a single rep, but the provider's official policy) I'd find competent provider. Woops - sorry for being misleading. I meant (and use) random numbers taken from within the private address ranges. (10.x.x.x etc) - 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] Re: multi-wan, multi-lan security
On Fri, Aug 06, 2010 at 09:51:35PM -0700, Dave Warren wrote: In message 24b7224eff7c4e19b1a43fd4df416...@dp2000xp Tortise tort...@paradise.net.nz was claimed to have wrote: My ISP advised us not use common private LAN addresses for this (common problem) reason. (I now use randomly generated addresses) I do hope you never need to contact the legitimate owner of whatever IPs you're using... Personally, if my provider gave me such advice (not just a single rep, but the provider's official policy) I'd find competent provider. He said random. He didn't say non-1918 space. 192.168.$RND(10,255).0/24 10.$RND(10,255).$RND(10,255).0/24 172.$RND(16,31).$RND(10,255).0/24 I work for a local ISP. The above is what I mean when I recomend businesses pick a random network. He may have meant what you thought he meant, but he didn't actually specify. -- Scott LambertKC5MLE Unix SysAdmin lamb...@lambertfam.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
[pfSense Support] Re: multi-wan, multi-lan security
In message b8ab6ffcb532416f938e8d117b87e...@dp2000xp Tortise tort...@paradise.net.nz was claimed to have wrote: - Original Message - From: Dave Warren dave-use...@djwcomputers.com To: support@pfsense.com Sent: Saturday, August 07, 2010 4:51 PM Subject: [pfSense Support] Re: multi-wan, multi-lan security In message 24b7224eff7c4e19b1a43fd4df416...@dp2000xp Tortise tort...@paradise.net.nz was claimed to have wrote: My ISP advised us not use common private LAN addresses for this (common problem) reason. (I now use randomly generated addresses) I do hope you never need to contact the legitimate owner of whatever IPs you're using... Personally, if my provider gave me such advice (not just a single rep, but the provider's official policy) I'd find competent provider. Woops - sorry for being misleading. I meant (and use) random numbers taken from within the private address ranges. (10.x.x.x etc) In that case, excellent advice and one I would absolutely agree with. I'm possibly overly sensitive on this particular issue just because I'm tired of dealing with it professionally, one of $DAYJOB's partners used to give out advice like this and we spent untold hours cleaning up. I hope no offense was taken, certainly none was intended on my part and if I came across to harshly, I do apologize. - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
