bug still present in 2.1.2011 build.

Upgraded to latest and everything seems to work now on simulated link down. Cheers!

Please put some proof behind this.

hehe i was about to open a ticket for that :)

nice to see its already fixed :)

@wallabybob:

Congratulations on your success.

You might care to note that /boot/loader.conf is not guaranteed to survive a firmware upgrade, /boot/loader.conf.local is supposed to survive a firmware upgrade (and has survived all my recent firmware upgrades).

Yup, sort of noticed that when I upgraded to the latest Beta release. I will take a look at the loader.conf.local file and add the proper info there.

Thank you for your help.

thats great news…

Not the place to ask i suppose but can you elaborate please.  I'm in a bit of a vLan mess here at the moment!

Also do you plan to support multiple captive portals?  Or can you send the vlan info to the radius server as part of the authentication process?

@SeventhSon:

Is it just me or are you using the 1.x way of doing MultiWAN on a 2.0 box?

You should be able to make just one group, with your two gateways in the same tier. They will loadbalance until one fails.

If you want to force traffic out of one interface, you can use a firewall rule and chose a Gateway.

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

Sure, that will work for load balancing, but the additional gateway groups are still necessary if you have some traffic you would like to go primarily out one WAN but failover to the other. Assigning to a specific WAN won't failover in case it's down. I have an environment where I use all three (balanced, and one with each WAN primary and the others secondary), so public wifi uses the second WAN and the LAN uses the first WAN by default but they both fail over. Actually I'm not sure if I'm even-balancing directly there or not but I do have it set as an option should I need it.

I could login with my tinycore vm so I guess it is an issue with security settings in 2008 r2

CONCLUSION

As a last 'hail mary pass', I decided to re-install pfSense 2.0 from a cd instead of using the 1.2.3 upgrade that was in place.  Within a few minutes, I had the IPSec mobile client tunnel configured and had connectivity to the protected LAN with a Shrew Soft client.  I can't say why.  I used all the same IPSec parameters on the server and didn't touch the client parameters at all.

Here are some other things I learned along the way:

1. UDP500 outbound NAT must be statically mapped.  Since this is now automatically generated, it is not an issue.

2. The IPsec implementation does not support multi-WAN failover, and gateway failover groups cannot be used in IPSec firewall rules.  This is unfortunate.  Giving it WAN failover functionality would make pfSense an excellent replacement for the Netgear FVS336G Dual WAN VPN Gateway my customer is trying to move away from.

3. SDPs can have mismatched ports after a change to the IPSec configuration.  This will prevent traffic from passing through the tunnel.  Restarting racoon clears this up, but is cumbersome.

4. Even though the Shrew Soft client works, the Netgear client still can't obtain an automatic virtual address.  However, if configured to, it can request and obtain a specific one.  Nonetheless, even though it and the server report an established tunnel, there is no connectivity with the server's LAN address or any computer in the LAN.  I'm abandoning the effort, though.  My goal is a working IPSec tunnel with an Avaya 4620SW IP phone.  The software client was only intended as a breadboard and the Shrew Soft client has obliged.

I'll open up a new thread with regard to the phone tests.

I was not hitting 100 % useage ( 1.4M-2M ) but the traffic overhead was somewhat too much on a not so good link ,changed apinger for a 60s interval instead of 1 second default .

In case anyone is interested, this is a simple script I use to backup several pfSense boxes daily.  Just set the parameters at the top of the script and add it to cron.  It excludes RRD data, gzips the xml file and deletes backups that are older than 30 days.

A couple of caveats…  It assumes the web interface of pfSense is using HTTPS.  If you're using HTTP, change the https:// lines to http://

Even though the script will backup multiple pfSense boxes, it assumes all pfSense installations are using the same web port.

It should be quite simple to modify the script if you need to specify HTTP/HTTPS and/or different ports for different installations, but it's not something I needed so didn't include it.

If you only need to backup one pfSense box, just enter a single IP/hostname for the SITES variable.  Hope someone finds it useful.

#!/bin/bash BACKUPDIR="/path/to/your/backups" USERNAME="backupuser" PASSWORD="backuppassword" PORT="1234" SITES="192.168.1.1 pfsense.local 10.10.10.1" GZIP="/bin/gzip" FIND="/usr/bin/find" BACKUPDAYS="30" for site in $SITES do         wget -qO/dev/null --keep-session-cookies --save-cookies /tmp/cookies.txt --post-data 'login=Login&usernamefld='$USERNAME'&passwor dfld='$PASSWORD'' --no-check-certificate --timeout=10 https://$site:$PORT/diag_backup.php > /dev/null 2>&1         if [ -e /tmp/cookies.txt ]; then         FILENAME="$BACKUPDIR/config-$site-`date +%Y%m%d%H%M%S`.xml"                 wget --keep-session-cookies --load-cookies /tmp/cookies.txt --post-data 'Submit=download&donotbackuprrd=1' --timeout=10 h ttps://$site:$PORT/diag_backup.php --no-check-certificate -O $BACKUPDIR/config-$site-`date +%Y%m%d%H%M%S`.xml > /dev/null 2>&1                 rm -f /tmp/cookies.txt         $GZIP $FILENAME         else                 echo "Failed to retrieve backup from $site"         fi done $FIND $BACKUPDIR -type f -name "*.xml.gz" -mtime +$BACKUPDAYS -exec rm {} \;

The above pic is my NAT port forward rules.  The rules themselves by interface are attached.  Its really frustrating, and seems to not be very consistent.  Sometime I can connect to to both interfaces with an L2TP connection, other times only the WAN IP.  It seems to also be related to the network i'm on.  I seem to have a lot of trouble connecting to the WAN2 IP when I am at home on a comcast cable modem, but I have another setup on the same IP block running DD-wrt with port forwarding to another VPN server and that works just fine.

fw-wan2.jpg
fw-wan2.jpg_thumb
fw-wan.jpg
fw-wan.jpg_thumb

@clarknova:

Yeah, I just need a one-off solution for testing new commits that address my issue. It wouldn't be entirely unattended either, as I have a remote system pinging my WAN, so if pfsense went down for more than 5 minutes I'd get a wake-up email anyway. I'll try Jim's suggestion next time I feel the need to grab the latest snap.

ahh - I mis-understood you. Would be interesting to hear if it all works for you.

Should be fixed on new snaps:

https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/5ded8bab169514e6c3ba0a58da6a00a9b4cc1689

https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/54eb029eea30213c8815ca534132a6ed03b44dd4

That entry is supposed to start with two colons, at least it does on all my installs.

I don't see any errors like that at all, and my VMs with serial console turned on work great.

OpenVPN and Windows 2008 Server / AD RADIUS authentication worked correctly after I made one change on the pfSense router. pfSense 2.0 BETA-5 (i386).

I had to create an Authentication Server profile that matched the friendly name of the Server 2008 RADIUS Clients setting, and the Connection Policy. That way I had a match in the "Backend for Authentication" selection name in the OpenVPN server settings.

Before making that change, I was able to make a connection to the router, but the RADIUS authentication would always fail.

However, I believe that you are right that in order to make OpenVPN work with Server 2008 RADIUS, the communication between pfSense and the RADIUS server needs to be unencrypted. Either via Group Policy or by telling the server that it's ok to listen for unencrypted passwords on that server's connection policy.

We've not run into this problem yet, but we are also using IGB on a powerful multicore server, so I'd be interested to see a resolution on this.

That holds across reboots and upgrades. Thanks