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] 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] 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] 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
Re: [pfSense Support] Bridge + Captive Portal
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. Now captive portal is requirement by the country (Thailand) that host our institute. 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
Olivier, Depending on the switches that you have, (like the HP procurves), you can make those switches serve up a captive portal before traffic can be sent to any other MAC address. I know that this isn't a pfSense "answer," but depending on the equipment that you have, you may be able to accomplish it. Is there a particular reason you are trying to do a captive portal using a bridge setup vs NAT? Dimitri Rodis Integrita Systems LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Buechler Sent: Tuesday, November 18, 2008 12:34 AM To: support@pfsense.com Subject: Re: [pfSense Support] Bridge + Captive Portal On Mon, Nov 17, 2008 at 11:15 PM, Olivier Nicole <[EMAIL PROTECTED]> wrote: > Hi, > > Sorry to bug, but the question is of some importance to me as I have > to select and implement a solution. > > Is pfSense can use bridge and captive portal at the same time? No, at least not that I'm aware of. It needs an IP to serve the portal content, and accessing it could be problematic in a bridged environment. - 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] Bridge + Captive Portal
On Mon, Nov 17, 2008 at 11:15 PM, Olivier Nicole <[EMAIL PROTECTED]> wrote: > Hi, > > Sorry to bug, but the question is of some importance to me as I have > to select and implement a solution. > > Is pfSense can use bridge and captive portal at the same time? No, at least not that I'm aware of. It needs an IP to serve the portal content, and accessing it could be problematic in a bridged environment. - 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
Hi, Sorry to bug, but the question is of some importance to me as I have to select and implement a solution. Is pfSense can use bridge and captive portal at the same time? How many interfaces are needed/for what purpose? 1- IPless, inside firewall 2- IPless, outside firewall 3- inside firewall, control interface (to access the web configuration) ? other Best regards, Olivier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Commercial support available - https://portal.pfsense.org
