up vote 1 down vote favorite
share [g+] share [fb]

Is it possible to configure pfSense in such a way that it acts as a bridge between two Ethernet interfaces, and has captive portal functionality? I want to use the captive portal package, but don't want any additional routing, DHCP, firewall, or anything else. We have other devices on our network to handle the other functionality.

Here is a boiled down version of the layout I want to achieve:

Network Diagram

Basically, the em0 interface of the pfSense box would be connected to our router, and then out to the Internet from there. The em1 interface would be connected to our internal network, where our servers, including DHCP server, clients, and everything else live. I would give it a list of MAC addresses to ignore (for our servers).

I have read through many pfSense forum posts that suggest this isn't possible, a couple that suggest it is. I have the bridge working, and have tried installing the captive portal on the bridge interface, but it doesn't do anything. I have enabled bridge filtering in the advanced options, but that seemed to have no effect.

How can I get this to work, if it possible?

link|improve this question
88% accept rate
feedback

2 Answers

up vote 1 down vote

As per openbsd doc (At some point anyway, pfsense was based on openbsd, as I recall - the pf packet filter is from Openbsd project) a bridge interface cannot have an IP, therefore it cannot be the captive portal:

http://www.openbsd.org/faq/faq6.html#Bridge

That said, perhaps you can try adding a third interface that does have an IP, and see if you can use PF rules to redirect traffic that crosses the bridge intended to someipaddr:80 to captive.portal.host:80 which is listening on that third leg of the pfsense system.

link|improve this answer
Thank you for your input. Suppose I tried to add another interface... can you provide some general direction on how to get this working? When you say add an interface, do you mean physical Ethernet interface, or something like OPT2? – Brad Jul 27 '11 at 19:35
physical interface. I would connect that third interface into the same LAN segment that the actual DHCP server is connected, assuming that the internal side of the pair of bridge interfaces is also connected into there. This way, you can rewrite traffic destined to go to blah.com:80 to go to captiveportal.internal.com:80 instead, and it should find it's way to this third interface which is listening for it. – sandroid Jul 27 '11 at 20:51
feedback
up vote 1 down vote

A bridge interface can have an IP. But there are a number of complications in trying to do what you're looking to accomplish, like getting an IP from DHCP unless it's running on the firewall itself, accessing DNS unless it's running on the firewall, and potentially other complications. I wouldn't recommend running captive portal like that, use either a routed or NATed subnet behind the portal.

link|improve this answer
Untangle does it in a bridged manner, and it is perfect for us... except its features for keeping track of who has "registered" and who hasn't doesn't meet our needs. I'm pocketing your suggestion for now, as I am not in control of the overall implementation. The folks who are don't want anything too complex, and are weary of putting a box inbetween major parts of the network unless there is an easy way to remove it. Routing isn't as simple as unplugging it, as we have with Untangle. – Brad Jul 28 '11 at 0:51
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.