So using the testing tool I get this:

Thu Dec  2 15:34:36 2010 : Auth: Login OK: [test/test] (from client DesktopTest port 0)

All appears to be working fine.  What in notice though is that the client it lists: DesktopTest.  With two different wireless access points and from the wireless card in the box it has never listed anything other than:

Thu Dec  2 15:35:06 2010 : Auth: Login incorrect: [test/<no user-password="" attribute="">] (from client pfSense port 0 cli 00-4A-92-B3-50-5F)

Each of the others is setup with its own client:

10.0.1.1 pfSense pfSense

10.0.1.5 Linksys DD-WRT Linksys Access Point

10.0.2.1 TestRADIUS Internal Wifi RADIUS Test

10.0.1.15 Linksys Linksys WRT54G

10.0.1.49 DesktopTest DesktopTestClient

Not sure why that is.</no>

Has been fixed. Thanks again and keep up the good work! Love it,

@Efonne:

That must be a bug in the code that hides it.  When you have "Force all client generated traffic through the tunnel." checked, the Local Network box is meaningless, since the route that the checkbox setting pushes to the client would cover anything you could put in the Local Network box.

It's not just an issue there really, upon further examination.

I just committed a change that will rerun the javascript (gwredir_change()) that shows and hides that box on every server mode change. I also noticed that the gateway redirect box was not being hidden when switching to shared key mode, it should be correctly disabled now.

Any news? can someone post a binary file?

True, true :-) But, the position of user on the outside getting in is still, I'd argue, a more sensitive one than the same user being inside going out. Generally. Maybe not the principle of least privilege in practice, but at least it's not captive portal users also able to VPN in by default :-)

I haven't seen this exact issue, but I've attempted to use the Traffic Graph recently to troubleshoot some bandwidth-hog problems and found that it seemed really random, IPs kept popping on and off the graph too fast to read and the Bit/sec numbers were often not high enough among the few IPs listed to add up to the overall throughput shown on the graph. It's a very cool idea but didn't help me troubleshoot this customer (I think they're running a snapshot from almost that same day) who has consistent internet slowdowns on Tuesday afternoons each week; I was hoping it would more easily show me bandwidth hogs in real time. Also, allowing a reverse DNS lookup option to be turned on would be very helpful rather than manually having to reverse each IP to see what's hammering, assuming they are accurate.

So I love the concept, but when it comes down to looking at individual hosts, the info seems less than accurate sometimes (but I can't exactly quantify it). I'd love to see some historical info where hosts don't disappear right away (they can grey-out when not transmitting, just not disappear), at least not for several more seconds (I wouldn't mind them sticking around forever and being shown in order of most bandwidth used since chart opened or most-throughput-now, or optionally both, choosable). Obviously what's there is better than nothing and better than a lot of what's out there already, but I'm brainstorming and dreaming :-)

I fixit.

Modify /etc/inc/filter.inc

2051 line

if(!isset($config['webgui']['port'])) { if($config['webgui']['protocol'] == "http") $webConfiguratorlockoutport = "80"; elseif($config['webgui']['protocol'] == "https") $webConfiguratorlockoutport = "443"; } else { $webConfiguratorlockoutport = $config['webgui']['port']; }

replace with

if(!isset($config['system']['webgui']['port'])) { if($config['system']['webgui']['protocol'] == "http") $webConfiguratorlockoutport = "80"; elseif($config['system']['webgui']['protocol'] == "https") $webConfiguratorlockoutport = "443"; } else { $webConfiguratorlockoutport = $config['system']['webgui']['port']; }

@geewhz01:

Ok thanks.  I'll test tomorrow :).

Thanks,

Andy

This is fixed for me.  THANKS!!!!

I do not know by the time they call me it is back up.

Thanks Jim.  I had forgotten about that option.  Will give it a try.  We are going to setup a test connection in my lab to the box in question.  Just not sure of a good way to monitor it.

That snap killed my systems.
I reinstalled a old one and still need to reconfigure everything…

Hello

I had the same problem and fixed as mxx said in this thread: http://forum.pfsense.org/index.php/topic,30655.0.html

Best

Hmm i might have the solution for you.
Please try setting net.link.ether.inet.useloopback = 0 under system->advanced->tunables.
Then retry your setup, with that it should work.

@Nachtfalke:

I just want to let you know, that this works fine. Syslog shows me the voucher code, MAC, IP and time.
But only in the external syslog server. The System logs in pfSense doesn't show me the vouchers and so on.

Further, I didn't get any info about DHCP Leases in pfSense System Log -> DHCP and nothing in my external syslog server.

I'm using pfSense 2.0BETA4 30.11.2010

Thanks for your help.

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

I went ahead and opened a ticket for this:
http://redmine.pfsense.org/issues/1062

I put 2.1 as the target, if someone feels like writing the code and getting in 2.0 it's possible, but given that it's a relatively minor thing it could go either way.

Thank you guys!

I'm really impressed.
@sullrich mille grazie for the commit!
@jimp thanks for the hint.

@TooMeeK: confirm - I've tested with FreeBSD 8.1. This panic only occurs on KVM running on AMD.
FreeBSD 8.1 on KVM running on Intel does not need the fix.

problem was snort issue,while downloading openssl part of squid snort was blocking download.

1 1 TCP GPL SHELLCODE x86 inc ebx NOOP Executable code was detected 66.111.2.166 80 -> xxx.xxx.xxx.xxx 6524 1:1390:5 12/01-11:36:2

i put 66.111.2.166 (packege repo) snort white list,problem resolved.

I can see from there the session but as you mention i cannot control the session. I setup Maximum state entries per host and Maximum number of established connections per host 50 but nothing working. When I check states summary it shows lot more higher some of clients.

Yeah it needs improvements.
I will see if i can make this work as intended for 2.0.

AFAIK it is possible.
Search the forums for the explanation. There is quite a long thread in this board for 2.0 according to that.