I just imaged a CF with the most current 1.2.3-RC3 nanobsd snapshot and setup captive portal with redirect and had no problems on my ALIX.

Here are the settings I used, with my IP addresses as an example:

OPT1 enabled, IP 192.168.15.1/24
DHCP Server on OPT1 enabled, range 192.168.15.10-20
OPT1 Firewall rules: Allow all protocols from OPT1 subnet to *
CP Enabled on OPT1, redirection URL is my personal domain
Authentication is local user database.
I added a user for myself, and then hooked into that subnet with my netbook.

When I try to go to (for example) imdb.com, and I get the login page. I login, then I am redirected to my personal domain.

You can already authenticate captive portal using Active Directory, using RADIUS.

Take the $50, go buy the pfSense book when it's available in about a week, and you'll find out how and still have about $10 left.  :)

This is already there in 2.0. It's not reasonable to back port, so you'll just have to wait for 2.0 to become stable, or live on the edge if it's not a critical environment.

You want this per user bases or for the traffic in general?!

For 2.0 it is very possible.

2.0

ok so I got it open now on both modems. just gotta make sure I got the DNS right.

http://forum.pfsense.org/index.php/topic,15785.0.html

Here is what I found on the DHCPREQUEST error.

First, I noticed an endless stream of entries on the Firewall log from 10.236.179.1 (a private address?) to, alternately, (a) the public ip address of my WAN, (b) 255.255.255.255:68, or © to 224.0.0.1.  The protocol indicated was either UDP or IGMP.  Sometimes no port was indicated, but more often port 67 or 68 would be indicated.  The entry would occur about every two minutes, but sometimes more frequently.

It occurred to me that this might be related to the DHCPREQUEST problem, although I have only the barest guess why.  If the cable modem is, for some reason, generating a DHCPREQUEST continually, it might be because the firewall rules are rejecting the request continually.  On further reflection, all of the problems might be related as they seem to stem from the cable modem's configuration.

I have done two things which seem to have addressed the problem.  First, I added a WAN firewall rule to pass a UDP or IGMP request from 10.236.179.1.  Second, I unchecked the box "Block private networks" on the WAN page.  It seemed, given the problems I have had with a private IP address on the cable modem, that it would help.

The DHCPREQUEST error is no longer appearing in my System log, and the Firewall log no longer shows that the traffic from 10.236.179.1 has been dropped.  It has been so long since my log files were really useful, given all of the repeated entries, that it is now a real pleasure to review them.

Having said and done this, I do not have a deep understanding of why this works, other than the obvious, or more importantly whether it is a good idea.  I am open to feedback on that just for my knowledge.

I think this has either already been done in 2.0, or is being worked on.

Just saw that I missed the second page of this thread and want to ask if headhunter_unit23 had a chance to test it.
Myself will try to find sometime this or next week to set this up.

Or anybody else tried OpenVPN in the described way ?

All posts indicate that pfSense cannot currently NAT VPN to a public IP. The phase 2 NAT for the source address suggested by ermal will do what you want which uses the features of your router to meet your peer's addressing requirements. If that seems backwards, it is since whatever it is they want you must administer which is necessary so long as first rate vendors insist on providing second rate products. It would be much better if the needs and the administration were at the same peer.

If your peer had phase 2 or policy NAT for the destination address they could handle their own needs without putting any restrictions on you and allow you to choose a low cost router that didn't have policy NAT. They are asking so their top brand router probably doesn't have it. Phase 2 NAT for source and destination are equally easy to implement so there's no good excuse for routers to implement one without the other. The presence of phase 2 NAT for both the source and destination would place pfSense among the best. Implementing all the features I've suggested including both phase 2 and policy NAT would make pfSense unbeatable at any price and would hopefully get the other vendors to get it right or get out.

172.20 isn't a public address but you probably used that as an example to avoid exposing your public subnet.

I have the same problem as you. A VPN router that can't at least phase 2 NAT is of no use to me and the reason I must buy way too much router for my network is the size of some other network. My peer's network is so large that they require all VPN to traverse with public IP addresses to minimize router quagmire. The necessary policies are always maintained to route public IP to the VPN peer. They have enough trouble routing random subnets around their own network without causing occasional VPN outages from inadvertent routing errors for the random subnets that must route to the VPN peer. Their customers like me must make up for the incomplete policy NAT implementation in their top brand router by buying our own top brand router since pfSense can't do it and low cost VPN routers refuse to implement even the trivial forms of phase 2 NAT.

I started with Cisco Pix v6.x which is definitely making money prolonging the problem. The lousy policy NAT implementation is tied to communication to the Internet which obfuscates how policy NAT works and creates unnecessary restrictions. It wasn't until I used policy NAT on the Fortigate where it is implemented correctly that I understood how simple policy NAT was and how the bad Cisco implementation had me hogtied.

Until you see how simple policy NAT is, it is difficult to match examples to your situation. NAT to a public subnet sounds different than a NAT to a private subnet so when you read the FortiOS Outbound NAT Examples it sounds like outbound NAT won't cover NAT to public IP though it does. The Pix policy NAT via static NAT adds to the confusion because Internet traffic is bound to the same address as the policy NAT so it seems like only public IP you are assigned will work and you need to buy IP addresses for each machine that communicates over a VPN. A good policy NAT implementation allows any arbitrary subnet to pass through the VPN without affecting the address used for the rest of the network, the Internet, and other VPN. Phase 2 NAT allows different addresses for different tunnels and policy NAT allows different addresses for different traffic should you ever need such maddening control over VPN NAT addressing.

The only communication to the NAT address occurs inside your peer's network which is the entire reason for their choice and why they want you to spring for a router than can provide what theirs can't. The ping to 172.20.1.1 travels through your peer's many routers until it hits the VPN peer where the address hides under the encryption and the packet goes out with the peer's own address to your VPN router. When the packet arrives the 172.20 address will disappear as your router NATs it to an address that your network will route. Return packets pass through the NAT process in reverse. VPN packets will not arrive at the NAT address they are sent to. The address disappears during transit. Packets arrive from a NAT address they were not sent from. The NAT address appears on packets during transit.

When a packet is inside either LAN the original and NAT IP addresses have meaning. When the packet hits a peer they are transported over the Internet using the peer addresses so the original and NAT ip addresses cease to have meaning until they pop out the other peer. It makes no difference whether the NAT IP is public or private since the Internet never sees communication from or to it. With a full implementation of policy NAT you don't care what subnet is. It is just numbers hidden inside the router. Let your peer choose the subnet if they want to. The subnet can be different for each peer. Public subnets you use do not need to be assigned to you. When you change ISP you can continue to use the old public subnet even though you are no longer assigned to it. You can provide as many public IP VPN targets as you need without having to buy a large static IP block and expand as needs increase. Even a single dynamic IP is sufficient.

Still 80$ can be contributed to pfSense or me i guess!
Though that is on your taste.

Please remove bounty

I have no problem with it getting the smack down!  :o

To which screen?  It's already there for IPsec.

Have you tried a clean install of 1.2 Release?  Without importing any of the old configuration?I would be curious if it would work with a clean pfSense box.