[pfSense Support] Multicast with pfSense
Hi, I am back to pfSense 1.2, how to define PIM protocol in the rules? How to configure pfSense to work with multicast? Best regards, Olivier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] A couple of questions regarding version 2.0
On Wed, Nov 19, 2008 at 9:30 PM, Olivier Nicole <[EMAIL PROTECTED]> wrote: > Hi, > > I am not sure if I am asking to the proepr list. > > 1) when version 2.0 will come to production? > http://doc.pfsense.org/index.php/When_Will_A_Release_Occur > 2) how to proceed to the updates in version 2? I installed > pfSense-20081029-2207.iso, now I am trying to update to > pfSense-Full-Update-2.0-ALPHA-ALPHA-20081119-1223.tgz via the web > configurator. It takes ages after I clicked on "Upgrade Firmware" > and nothing happens, the web browser is stuck on waiting. > that should work. try console upgrade. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Commercial support available - https://portal.pfsense.org
[pfSense Support] A couple of questions regarding version 2.0
Hi, I am not sure if I am asking to the proepr list. 1) when version 2.0 will come to production? 2) how to proceed to the updates in version 2? I installed pfSense-20081029-2207.iso, now I am trying to update to pfSense-Full-Update-2.0-ALPHA-ALPHA-20081119-1223.tgz via the web configurator. It takes ages after I clicked on "Upgrade Firmware" and nothing happens, the web browser is stuck on waiting. Best regards, Olivier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] Bridge + Captive Portal
On Wed, Nov 19, 2008 at 8:22 PM, Olivier Nicole <[EMAIL PROTECTED]> wrote: > > I think (from what I tried/looked) that rdr to localhost is not > compatible with bridging: bridge can only pass (or block) packets > between the two interfaces that are bridged, it cannot redirect the > packets to somewhere else. > I briefly tried enabling CP on a bridged interface earlier. What happens is the rules don't get added properly because it relies on the IP address of the interface you're using for CP. Since the bridged interface doesn't have an IP, the rules added are incomplete. One possible hack is putting an IP on the LAN that's on the same subnet as those hosts. You can assign an IP to LAN and bridge it simultaneously. That seems to be troublesome if WAN is also on the same subnet though, so you may need another hack there. There probably is a workable solution with having an IP on LAN and bridging it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] Bridge + Captive Portal
> He still needs an IP on some interface for management (presumably > LAN). True. Well in fact its a thrid interface, that makes the rules easier to manage. > Any chance CP could be used on that interface? It's been so > long since I've looked at CP, I don't remember what we're doing under > the covers to force the http traffic to the portal (just an rdr to > localhost if memory serves). I think (from what I tried/looked) that rdr to localhost is not compatible with bridging: bridge can only pass (or block) packets between the two interfaces that are bridged, it cannot redirect the packets to somewhere else. Olivier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] Bridge + Captive Portal
> Besides that, if you want to make use of the public IPs, why not set up 1:1 > NAT mappings for all of your public IPs and then just set your DHCP pool on > your LAN interface to use the corresponding private IPs? That way, you can > "use" all your public IPs, and each client will have one-- I've never used > 1:1 in conjunction with captive portal, though, so what I just said may or > may not work. I am not sure how captive portal works, but I would think that it does not need NAT, only redirection (which is part of NAT, but is not really NAT). So I beleive captive portal can work with using public IP on the LAN interface, no need for address translation. Bests, Olivier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] pfSense and dynamic routing
On Wed, Nov 19, 2008 at 6:29 PM, Bill Marquette <[EMAIL PROTECTED]> wrote: [snip] > At this point we should probably move it to stable as it's > been around a while and has had no bug reports. Done. Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] pfSense and dynamic routing
On Wed, Nov 19, 2008 at 8:07 AM, Veiko Kukk <[EMAIL PROTECTED]> wrote: > Erwan David wrote: >> >> OpenBGPD is in the packages. > > Thank you, but is it stable enought (ALPHA)? Are there any plans to make > Quagga package for pfSense? The software itself is stable. The pfsense wrapper package is marked alpha. At this point we should probably move it to stable as it's been around a while and has had no bug reports. --Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] Bridge + Captive Portal
On Wed, Nov 19, 2008 at 2:09 AM, Chris Buechler <[EMAIL PROTECTED]> wrote: > On Wed, Nov 19, 2008 at 1:58 AM, Olivier Nicole <[EMAIL PROTECTED]> wrote: >> Hi Dimitri, >> >> Thanks for the clues, i will look at what i can do with the switch. >> >>> Is there a particular reason you are trying to do a captive portal using a >>> bridge setup vs NAT? >> >> We have the right amount of public IP available (only a class C, but >> for around 150 users, that's plenty enough), so no reason to NAT. >> >> I have been running a bridged firewall (FreeBSD + ipf) for ages (since >> FreeBSD 4.0 maybe), it is working smoothly, it is invisible (obscurity >> is not security, but it contributes to security), it simplifies >> routing (one less hop) and in case of problem, it can be replaced with >> an Ethernet cable. That's among the reasons why I like bridged >> firewall. >> > > All valid, but a captive portal implementation by definition cannot be > transparent. It has to redirect hosts to an IP on one of its > interfaces to serve the portal content. He still needs an IP on some interface for management (presumably LAN). Any chance CP could be used on that interface? It's been so long since I've looked at CP, I don't remember what we're doing under the covers to force the http traffic to the portal (just an rdr to localhost if memory serves). --Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] Application Layer Classification
Does that mean pfSense 2.0 will indeed have this functionality? Or is it at least on the roadmap? Tim Nelson Systems/Network Support Rockbochs Inc. (218)727-4332 x105 - "Chris Buechler" <[EMAIL PROTECTED]> wrote: > On Wed, Nov 19, 2008 at 3:29 PM, Tim Nelson <[EMAIL PROTECTED]> > wrote: > > Good afternoon (here at least)- > > > > Hot on the heels of this new blog: http://roadtoqos.wordpress.com/ > as referenced on the pfSense blog, I've started thinking a bit about > the possibilities. > > > > If I understand it right, using ipfw-classifyd QoS can be set based > upon layer 7 information. With the ability to classify traffic based > on content inspection rather than simple network/port/protocol > characteristics, does this mean that ipfw-classifyd will allow > FreeBSD, more specifically pfSense to traffic shape and firewall based > upon those characteristics? > > yes > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > Commercial support available - https://portal.pfsense.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] Application Layer Classification
On Wed, Nov 19, 2008 at 3:29 PM, Tim Nelson <[EMAIL PROTECTED]> wrote: > Good afternoon (here at least)- > > Hot on the heels of this new blog: http://roadtoqos.wordpress.com/ as > referenced on the pfSense blog, I've started thinking a bit about the > possibilities. > > If I understand it right, using ipfw-classifyd QoS can be set based upon > layer 7 information. With the ability to classify traffic based on content > inspection rather than simple network/port/protocol characteristics, does > this mean that ipfw-classifyd will allow FreeBSD, more specifically pfSense > to traffic shape and firewall based upon those characteristics? yes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Commercial support available - https://portal.pfsense.org
[pfSense Support] Application Layer Classification
Good afternoon (here at least)- Hot on the heels of this new blog: http://roadtoqos.wordpress.com/ as referenced on the pfSense blog, I've started thinking a bit about the possibilities. If I understand it right, using ipfw-classifyd QoS can be set based upon layer 7 information. With the ability to classify traffic based on content inspection rather than simple network/port/protocol characteristics, does this mean that ipfw-classifyd will allow FreeBSD, more specifically pfSense to traffic shape and firewall based upon those characteristics? It would be fantastic to have the ability to shape/block traffic by content... Thoughts anyone? Tim Nelson Systems/Network Support Rockbochs Inc. (218)727-4332 x105 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Commercial support available - https://portal.pfsense.org
RE: [pfSense Support] Bridge + Captive Portal
The HP implementation on the procurve line places you on a temp vlan until you authenticate. Once you do, your port membership changes. Besides that, if you want to make use of the public IPs, why not set up 1:1 NAT mappings for all of your public IPs and then just set your DHCP pool on your LAN interface to use the corresponding private IPs? That way, you can "use" all your public IPs, and each client will have one-- I've never used 1:1 in conjunction with captive portal, though, so what I just said may or may not work. Dimitri Rodis Integrita Systems LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Buechler Sent: Wednesday, November 19, 2008 12:10 AM To: support@pfsense.com Subject: Re: [pfSense Support] Bridge + Captive Portal On Wed, Nov 19, 2008 at 1:58 AM, Olivier Nicole <[EMAIL PROTECTED]> wrote: > Hi Dimitri, > > Thanks for the clues, i will look at what i can do with the switch. > >> Is there a particular reason you are trying to do a captive portal using a >> bridge setup vs NAT? > > We have the right amount of public IP available (only a class C, but > for around 150 users, that's plenty enough), so no reason to NAT. > > I have been running a bridged firewall (FreeBSD + ipf) for ages (since > FreeBSD 4.0 maybe), it is working smoothly, it is invisible (obscurity > is not security, but it contributes to security), it simplifies > routing (one less hop) and in case of problem, it can be replaced with > an Ethernet cable. That's among the reasons why I like bridged > firewall. > All valid, but a captive portal implementation by definition cannot be transparent. It has to redirect hosts to an IP on one of its interfaces to serve the portal content. I'd just use a /30 on the WAN, and your public IP block on the LAN, disable NAT, enable captive portal, and you're set. You can still have the "remove the firewall" option by adding your LAN IP on the upstream router if necessary, and removing the firewall. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Commercial support available - https://portal.pfsense.org smime.p7s Description: S/MIME cryptographic signature
Re: [pfSense Support] pfSense and dynamic routing
On Wed, Nov 19, 2008 at 9:07 AM, Veiko Kukk <[EMAIL PROTECTED]> wrote: > Erwan David wrote: >> >> OpenBGPD is in the packages. > > Thank you, but is it stable enought (ALPHA)? Are there any plans to make > Quagga package for pfSense? # uptime 3:50PM up 196 days, 16:46, 2 users, load averages: 0.00, 0.00, 0.00 Neighbor ASMsgRcvdMsgSentOutQ Up/Down State/PrefixRcvd Wireless 4261 643775 643849 0 01:35:48 1 MetroE426116991661699127 0 13w0d22h 1 It is more than stable... Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] pfSense and dynamic routing
Erwan David wrote: OpenBGPD is in the packages. Thank you, but is it stable enought (ALPHA)? Are there any plans to make Quagga package for pfSense? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] pfSense and dynamic routing
On Wed, Nov 19, 2008 at 12:15:25PM CET, Veiko Kukk <[EMAIL PROTECTED]> said: > Hi, > > I need to use BGP and/or OSPF with pfSense. How can I use those > protocols? In web interface, I see only RIP. > OpenBGPD is in the packages. -- Erwan David == Trusted Logic Tel: +33 1 30 97 25 03 5 rue du BailliageStd: +33 1 30 97 25 00 78000 Versailles Fax: +33 1 30 97 25 19 France - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Commercial support available - https://portal.pfsense.org
[pfSense Support] pfSense and dynamic routing
Hi, I need to use BGP and/or OSPF with pfSense. How can I use those protocols? In web interface, I see only RIP. -- Veiko Kukk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] Bridge + Captive Portal
> All valid, but a captive portal implementation by definition cannot be > transparent. It has to redirect hosts to an IP on one of its > interfaces to serve the portal content. I once designed a prototype where the authentication interface was located on the outside of the firewall; the firewall had 3 interfaces: - one inside, IP less, bridged to the outside if - one outside, IP less, bridged to the inside if - one outside, with private IP, used for authentication But it was an homemade system and was not very reliable. > I'd just use a /30 on the WAN, and your public IP block on the LAN, > disable NAT, enable captive portal, and you're set. Of course. > You can still have the "remove the firewall" option by adding your LAN > IP on the upstream router if necessary, and removing the firewall. Of course too. Thanks, Olivier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] Bridge + Captive Portal
On Wed, Nov 19, 2008 at 1:58 AM, Olivier Nicole <[EMAIL PROTECTED]> wrote: > Hi Dimitri, > > Thanks for the clues, i will look at what i can do with the switch. > >> Is there a particular reason you are trying to do a captive portal using a >> bridge setup vs NAT? > > We have the right amount of public IP available (only a class C, but > for around 150 users, that's plenty enough), so no reason to NAT. > > I have been running a bridged firewall (FreeBSD + ipf) for ages (since > FreeBSD 4.0 maybe), it is working smoothly, it is invisible (obscurity > is not security, but it contributes to security), it simplifies > routing (one less hop) and in case of problem, it can be replaced with > an Ethernet cable. That's among the reasons why I like bridged > firewall. > All valid, but a captive portal implementation by definition cannot be transparent. It has to redirect hosts to an IP on one of its interfaces to serve the portal content. I'd just use a /30 on the WAN, and your public IP block on the LAN, disable NAT, enable captive portal, and you're set. You can still have the "remove the firewall" option by adding your LAN IP on the upstream router if necessary, and removing the firewall. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Commercial support available - https://portal.pfsense.org
