Re: [pfSense Support] Bridge + Captive Portal

2008-11-19 Thread Chris Buechler
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

2008-11-19 Thread Olivier Nicole
 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

2008-11-19 Thread Dimitri Rodis
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

2008-11-19 Thread Olivier Nicole
 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

2008-11-19 Thread Olivier Nicole
 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

2008-11-19 Thread Chris Buechler
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

2008-11-18 Thread Chris Buechler
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

2008-11-18 Thread Dimitri Rodis
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

2008-11-18 Thread Olivier Nicole
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

2008-11-17 Thread Olivier Nicole
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