Just what I was looking for! I want to protect the network at the WPA level (to completely keep out the curious) and use the captive portal for TOS. This isn't a public network, but it isn't entirely private, either. The idea is for contractors and consultants and such to be able to get internet access. They get the password from us, then have to agree to the TOS before continuing.

I was thinking it'd be nice to have somebody enter their name before clicking "Agree and Continue", but it didn't show up the logs. This patch fixes that! Thanks so much!

It would be nice to prevent them from leaving it blank, too. Maybe an option in the UI for "No authentication but still require (and log) a username"?

+1 on this feature.

When I define a custom portal page, then click the "view current page" link, I get "An error occured. Please check the system logs for more information."

System log says "php[51829]: /index.php: Captive portal could not deterimine clients MAC address. Disable MAC address filtering in captive portal if you do not needs this functionality."

The "view current page" for my Authentication error page contents does work, but it doesn't load any CSS or images.

So I can't preview the custom page, but it shows up fine when I'm actually using the captive portal (connecting from that interface). Bad password error page comes up w/ its CSS and images too.

If I check the "disable MAC filtering" option, the preview page for the "portal page contents" does come up, but the "authentication error page contents" still comes up minus CSS and images.

When I connect from the captive portal interface, there is no error about can't determine client's MAC address.

Add me to the "works here" list too.

And they're gone again today. Just curious what's up?

I upgraded today (with the manual firmware upload button) to 1.2.3-20090718-1920 on a non-production box without any obvious errors. Maybe something broke between the 18th and 19th?

Anyone else care to chime in? I have a maintenance window tomorrow and I was hoping to upgrade from my Feb 19th 1.2.3 to current, but it sounds like I may need to hold off...?

I can confirm this as well. Updated from 1.2.1-rc? to 1.2.3-PRERELEASE-TESTING-VERSION built on Thu Feb 19 21:52:48 EST 2009.

The package was not installed before the upgrade, nor was it present in the installed packages list after.

Cool, thanks.

The & seems to come back every time you click "save" on the Snort config page, tho. Would be nice to get this fix committed. ;-)

On more thing (sorry).

If I run a continuous ping through the tunnel, every once in a long while, I get a solitary reply.

When it doesn't work, tcpdump on the WAN interface looks like this. Note the "bad udp cksum" on the response:
15:21:37.183958 00:0b:db:94:4c:3f > 00:13:f7:36:4f:ac, ethertype IPv4 (0x0800), length 142: (tos 0x0, ttl 126, id 49678, offset 0, flags [none], proto UDP (17), length 128) 74.93.31.17.59491 > 192.150.143.211.500: [no cksum] isakmp 4.14 msgid  cookie ->: phase 2/others ? #214[C]: [|#200] (len mismatch: isakmp 2089828598/ip 100)       
15:21:37.220137 00:13:f7:36:4f:ac > 00:0b:db:94:4c:3f, ethertype IPv4 (0x0800), length 142: (tos 0x20, ttl 52, id 28569, offset 0, flags [none], proto UDP (17), length 128) 192.150.143.211.500 > 74.93.31.17.59491: [bad udp cksum dea7!] isakmp 9.15 msgid  cookie ->: phase 2/others ? #138[C]: [|#164] (len mismatch: isakmp 2342990064/ip 100)

When it does work, it looks like this. Note the "udp sum ok" on the response packet.
15:21:48.179080 00:0b:db:94:4c:3f > 00:13:f7:36:4f:ac, ethertype IPv4 (0x0800), length 142: (tos 0x0, ttl 126, id 6906, offset 0, flags [none], proto UDP (17), length 128) 74.93.31.17.59491 > 192.150.143.211.500: [no cksum] isakmp 15.11 msgid  cookie ->: phase 2/others ? #124[EC]: [encrypted #117] (len mismatch: isakmp 2676507093/ip 100)
15:21:48.217091 00:13:f7:36:4f:ac > 00:0b:db:94:4c:3f, ethertype IPv4 (0x0800), length 142: (tos 0x20, ttl 52, id 28678, offset 0, flags [none], proto UDP (17), length128) 192.150.143.211.500 > 74.93.31.17.59491: [udp sum ok] isakmp 8.8 msgid  cookie->: phase 2/others ? #134[C]: [|ke] (len mismatch: isakmp 168770057/ip 100)

It seems like checksums are wrong because of some kind of mangling, but every once in a while the mangled packet checksum ends up actually being right? Just a "monkeys on typewriters" kind of a thing?

More info:

It appears the remote VPN concentrator supports only NAT-T draft-01, which was replaced by NAT-T draft-02 because it was broken by some firewalls. Apparently draft-02 was when they started using port 4500 for payload. Before that it was port 500 for everything. So this might explain tcpdumps like this (on the LAN interface):

14:33:56.463083 IP (tos 0x0, ttl 127, id 272, offset 0, flags [none], proto UDP (17), length 128) 10.25.30.128.500 > 192.150.143.211.500: [no cksum] isakmp 1.7 msgid  cookie ->: phase 2/others ? #153[EC]: [encrypted #234] (len mismatch: isakmp 2582666284/ip 100)

Somebody else had a similar problem a while back. No resolution reported:
http://forum.pfsense.org/index.php/topic,9669.0.html

(I've tried everything in that thread already.)

Nope, no blocks in the firewall logs whatsoever. I've got it wiiiide open for testing. Packets are just getting mangled somehow.

I'm running a recent RC2 build. I have somebody on the inside of my pfSense trying to connect to a Juniper VPN concentrator on the internet. The tunnel comes up, but no traffic will go through it. I have a number of Cisco software VPNs working from the inside, so there's something unique about this Juniper one.

Rules permit all trafic into LAN, and all traffic from VPN conentrator IP on the internet back into WAN. I am using NAT, and IPSec NAT traversal is enabled with the (not working) Juniper connection, as it is with the (working) Cisco connections.

We put the machine outside the pfSense directly on the internet and the tunnel worked great. We put it back inside pfSense and did some packet sniffing with a hub on the internet connection. As usual the tunnel would negotiate, but no payload comes through.

Wireshark showed malformed isakmp packets and suggested "maybe caused by "UDP checksum offload". So I experimented with turning checksum offloading off in pfSense, as well as pf scrub. Didn't make a difference. Packet dump attached.

It does seem like some kind of fragmentation thing that pfSense isn't happy about. Any ideas?

Perry: Now that makes sense. And you're correct, they all do show up with a mouseover. It's just truncating the list for space considerations...? Can anyone confirm that?

Also I can edit the other aliases and it behaves exactly as expected. It's just the one alias that misbehaves. It is the one with the most entries, but it's only 12 long...