Thanks.  Any pointers to documentation for setting this up?  If not I'll try to figure it out…

huh, yeah it's possible that triggered the other issue, was panicing in ath but that doesn't necessarily mean anything.

http://redmine.pfsense.org/issues/1073

You can't hash things the system must have in plaintext in order to function.
http://doc.pfsense.org/index.php/Why_are_some_passwords_stored_in_plaintext_in_config.xml%3F

No problem, it took me a while to figure it out myself originally, too–used to version 1.2.3 and no real docs with 2.0 yet in many ways, but I've done it a few times now (and read a lot in the forums), so I'd (almost!) consider myself a pro at version 2 IPsec now :-) Even got it working to Endian as the other endpoint in a site-to-site, and with iPhone from Mobile clients. Also if you use the Shrewsoft VPN client I have a forum post showing a tweak you need to make in the latest version to make it connect as a Mobile client.

Once you're used to it, the configuration for IPsec in pfSense 2 is awesome, and very flexible. I can barely stand using 1.0 now because of the stuff in 2.0 such as using DHCP to assign IP addresses, iPhone/Mobile support with multiple subnets (phase 2s) accessible and pushed to the client with split DNS functional...pretty sweet setup! Even using most other IPsec endpoints like Endian feels so inflexible after using version 2! But fortunately pfSense has enough settings that with some experimenting you can usually get it working with pretty much any other IPsec endpoint, even though it's not nearly as flexible as pfSense-to-pfSense in range of options.

Voona maybe take a minute to add a comment to the bug? As for custom sigs, they mention it in the L7 portion of the traffic shaping guide. I'm guessing eventually they'll have their own write-up for it, but for now they mention taking a look at the sourceforge page.

http://doc.pfsense.org/index.php/Traffic_Shaping_Guide#Layer_7

http://l7-filter.sourceforge.net/Pattern-HOWTO

I updated to the latest snap to test the patch file.
I am not having any luck, but I am not a programmer. :)
The original auth.inc file that Juve posted does work in the new snap for open VPN, but not sure if anything else is broken since the file was changed allot. (As jimp noted)
Juve, I hate to ask but have you worked on this with new snaps?  Please let me know if I can help.
Without group searches, I think this severely hurts the AD lookup function. (IMHO)

Had an opportunity to test with the version below - "CARP VIP problem" is gone, thanks!

2.0-BETA4 (i386)
built on Sat Dec 4 01:44:52 EST 2010

Yeah sorry, I tried searching for the issue but couldn't find any recent topics, hence the skip of update.
Anyhow it really seems to be resolved with the newer snapshots, so thanks!  :)

Fixed in 8.1-RELEASE-p2 FreeBSD 8.1-RELEASE-p2 #1: Sat Dec  4 01:43:08 EST 2010  :D

clog -f dhcpd.log Dec  5 08:40:08  dhcpd: Internet Systems Consortium DHCP Server 4.1.1-P1 Dec  5 08:40:08  dhcpd: Copyright 2004-2010 Internet Systems Consortium. Dec  5 08:40:08  dhcpd: All rights reserved. Dec  5 08:40:08  dhcpd: For info, please visit https://www.isc.org/software/dhcp/ Dec  5 08:40:08  dhcpd: Wrote 0 deleted host decls to leases file. Dec  5 08:40:08  dhcpd: Wrote 0 new dynamic host decls to leases file. Dec  5 08:40:08  dhcpd: Wrote 5 leases to leases file. Dec  5 08:40:08  dhcpd: Listening on BPF/re0/00:1c:c0:c4:da:44/192.168.0.0/24 Dec  5 08:40:08  dhcpd: Sending on  BPF/re0/00:1c:c0:c4:da:44/192.168.0.0/24 Dec  5 08:40:08  dhcpd: Sending on  Socket/fallback/fallback-net Dec  5 08:41:15  dhcpd: DHCPREQUEST for 192.168.0.10 from 00:15:f2:a7:45:4d via re0 Dec  5 08:41:15  dhcpd: DHCPACK on 192.168.0.10 to 00:15:f2:a7:45:4d via re0

That solved it, thanks.

Figures that it was something simple like that. I'd completely forgotten that I'd reassigned the interfaces. [homer]D'OH[/homer]

Port forwards on WAN only work for traffic coming in on WAN, so you are actually accessing the router there, not your web server on the LAN.

http://doc.pfsense.com/index.php/Why_can't_I_access_forwarded_ports_on_my_WAN_IP_from_my_LAN/OPTx_networks%3F

Btw it does the same on sk1 - i.e.e WAN.  It will say hotplug event detected, link down, and sometimes not DHCP.

nevermind…

found a bug in redmine : http://redmine.pfsense.org/issues/829

will update this ticket instead.

My apologies for not being more accurate. Static problems are obviously very different, I should have been more explicit.
That is another issue that I will raise later.
As to waiting forever, half hour or more is forever for an issue of this type. I left it trying to get dhcp service and went home.
If I connect a computer to either network it successfully gets configured by dhcp almost instantly.
I will investigate more on Monday as per your suggestions.
Thanks

@ermal:

Its just a way to tell pf(4) to not do fancy tracking of tcp sequences but just keep state of packets.
It just matters for tcp.

In case anyone is wondering, from the man (5) page for pf.conf, I found this description of sloppy state tracking:

sloppy           Uses a sloppy TCP connection tracker that does not check sequence           numbers at all, which makes insertion and ICMP teardown attacks way           easier.  This is intended to be used in situations where one does           not see all packets of a connection, e.g. in asymmetric routing           situations.  It cannot be used with modulate or synproxy state.

Note the word asymmetric in the description.

Anyone have any idea's?

I checked in another fix, this one should work.

With your array and the code I just checked in, I get:

string(162) "CN=redacted.example.com, OU=PlatinumSSL, OU=L&S-Social Sciences, O=University of California, Davis, street=One Shields Ave, L=Davis, ST=CA, postalCode=95616, C=US"

rebooted, re updated, rebooted

Fatal error: Cannot redeclare csrf_startup() (previously declared in /usr/local/www/guiconfig.inc:39) in /usr/local/www/guiconfig.inc on line 38

Andrew

Should be fixed now.  Reinstall the package and you should be getting the correct URL.