No clues from the logs - but picking up on some previous comments.  It appears in my scenario that DPD is not working is terms of forcing a disconnect when the link is dead/inactive.

The 2.0.2 box shows the in vpn as inactive and the logs are full of no response/timeout errors - the the 2.1 beta is sitting there saying the link is active and that the last activity was some hours ago!  DPD is set to 10 secs and 5 retries at both ends.

If the 2.0.2 box is restarted it tries hard to make the link - but is completely ignored by the 2.1 beta - as the link is till active??  Do the reverse and force the 2.1 box to restart and the 2.0.2 box detects the missing peer and initiates a new link perfectly.

SO DPD broken in 2.1?
Andrew

Look in /etc/version*

[2.1-BETA1][admin@xxx]/etc(18): ls -l /etc/version* -rw-r--r--  1 root  wheel  10 Feb  3 08:52 /etc/version -rw-r--r--  1 root  wheel  29 Feb  3 09:08 /etc/version.buildtime -rw-r--r--  1 root  wheel  41 Feb  3 09:08 /etc/version.lastcommit -rw-r--r--  1 root  wheel  4 Feb  3 08:52 /etc/version_base -rw-r--r--  1 root  wheel  4 Feb  3 08:52 /etc/version_kernel

These files have interesting data about the build. e.g.:

[2.1-BETA1][admin@xxx]/etc(15): cat version.lastcommit 990fa101b6a2ce09e813a8d58f0f43178e54fc45

Then you can go to that commit on Github:
https://github.com/bsdperimeter/pfsense/commit/990fa101b6a2ce09e813a8d58f0f43178e54fc45
and see what it was, then browse that and earlier commits to see what the build contained.

Loading green_saver.ko and configuring with vidcontrol with the afterbootupshellcmd and getting the following message.   It does clear the screen though.

vidcontrol: getting active vty: Inappropriate ioctl for device'

Details:

/cf/conf/config.xml
<afterbootupshellcmd>/var/After_Bootup_Shell_Cmds.sh</afterbootupshellcmd>

/var/After_Bootup_Shell_Commands.sh
#!/bin/sh

After Bootup Shell Commands Script

kldload -v green_saver.ko;
vidcontrol -t 60

Log Output
php: : The command 'kldload -v green_saver.ko; vidcontrol -t 60' returned exit code '1', the output was 'Loaded green_saver.ko, id=2
vidcontrol: getting active vty: Inappropriate ioctl for device'

Thread split

Oh, and studiox, please don't use "Report to Moderator" to complain about being asked to start your own threads…

i tried the newest snap just today again and it seems to work fine now, saving under wifi brings back wifi back to normal without issues

Backing up libraries…
Removing package...
Starting package deletion for squidguard-1.4_4-amd64...done.
Removing squidGuard components...
Tabs items... done.
Menu items... done.
Services... done.
Loading package instructions...
Deinstall commands...

i've been useing all the updates like 2 weeks and no problem.

i have upgraded to todays release

You need to be on 2.0.3 code to fix this issue.
There is no way around it on 2.0.2

thank you bro, ill start a new thread

That is awesome!!! … Thanks Ermal it is working like a charm now.

It was an issue generated from rearranging some v6 code.
Latest git code or snapshot should behave correctly.

Yeah latest snap has the fixes.

Server is fine, there's a broken patch preventing the build from completing.

merged, thanks Phil.

@phil.davis:

I only have the 1 ordinary filterdns for pf.

Phil: Well, that might be difference, since in my test-VM I (should) have 2 filterdns processes (one for pf-fw-aliases and another for ipsec). The "ordinary" filterdns seems to work for me too, it's the ipsec-related one that bombs out …

Ermal: I don't see what good a full re-install from sceatch will do (I guess in IT it's standard procedure LOL), but I'll try it anyway.

Update: I'm happy to report that I just upgraded the existing VM to the very latest snap (from 29-Jan to 30-Jan-2013 04:20:11 EST) and filterdns now seems to work correctly for ipsec too! Only odd thing I've noticed is that the /var/run/filterdns*.pid files seem to have old time-stamps.

Thanks, I will give it a try.

@ermal:

Should be fixed on next coming snapshots.

OK thx… if it helps... "pure" NAT broke between snapshot Jan-25-11:45 and Jan-25-17:45 ...

NAT with gateway groups broke somewhere after 22th 05:55 image

Bests

Yes. The last build of yesterday the 28th is a dud.

Screwed up my install as my dual Intel NIC was not getting picked up.

Went back to Saturday.

It crashed and rebooted again after 28h of uptime. Now I set the traffic shaping only for the LAN interface instead on the bridged (LAN + WLAN) see if it make any difference.

found it, setting lan interface to 1492 and wifi to blank causes the above issues i mentioned, removing the 1492 from lan to blank solves it

Recreated the RADIUS config and I must have made some thing different this time.

It work perfectly now! OpenVPN is ready to replace PPTP!

Didn't suspect the RADIUS config first because it worked so well with the PPTP-server.

So with that, I can confirm that there is no problem with the RADIUS Auth-server part in current build of pf.

Brgs,