I had the same problem today after a manual update to JIMPs i386-20110929-1702.tgz I used Putty to get access into the console and ee to apply the fix above. Thanks to those who took the time to debug this and save me lots of time.

Reboot the pfsense box, I had this same issue. If you change the timezone I think you are supposed to reboot to make everything jive.

I SOLVE IT !!!! It was my mistake. The upgrade was not the problem. I used remote access with auth and the company asked me not to use auth but only certificate. So by mistake instead of choose remote access (without auth) I choosed peer to peer !!!! Changing it back to remote access the client export utility works fine again. But I wonder why openvpn server worked with peer to peer….  ??? Finally everything is OK now ! :)

Figured out what was wrong. Active Directory was setup only for Native 2000, and was not allowing me to select the option of "Control access through Remote Access Policy" Once I upgraded the domain to a 2003 domain, the option became available and I was able to use the IAS policies to control access. Cheers.

I finally knew the problem. I tried changing my domain name in System>General Setup. But when I checked with my PC and the scanner machine, the domain name was the previous domain. I did an ipconfig/flushdns, restarted the NIC of my PC but still the same. So I checked with the DHCP server, under Domain name, I specified my previous domain name. Even if I change the domain name, I always get my previous domain. I empty the box under Domain name, did a flushdns and restarted the scanner and everything is now ok. I still don't get it how that option affected my LAN. Anyway, thanks to all especially WALLYBOB for helping me with this.

May i make assumption. DHCP was serving .1 address as gateway and pfsense were .2?

Yeah, that's what I'm afraid. I might just use squid or varnish instead.  (I'm looking for a very lightweight HTTP CONNECT capable proxy server and tinyproxy sounded perfect but I don't want to break pfSense and tinyproxy has a ton of dependencies…)

Here are the commits and bug fixes: http://redmine.pfsense.org/projects/pfsense/roadmap This should help you find what you are looking for.

@Nachtfalke: whitlist allows the traffic always even if there is another rule with higher priority which blocks traffic. Whitlist: allows always allow: allows only if there is no other rule which blocks. Hope this makes it a little bit clearer !? wow! perfect man! Thank you so much!

Excellent, thanks guys.. its all working nicely.  Just wish i could get my public IP block forwarded so easily!! lol

I think not working on Chrome should be cause enough to call it a bug; Let alone the big base of clients that IE has. Anyhow, not trying to make this a philosophical issue but I think it can qualify as a bug if it ONLY works in Firefox. I can't test it on Firefox as I don't have it. I can also live with the bug as it's doesn't effect the functions but it's an aesthetic issue.

I think I found a better way of handling this.  I created a new schedule and that seems to work.

Why do you keep asking this 192.168.1.254 for time, who is he trying to sync with?  And where is your pfsense box set to sync with? Is this address on your WAN or LAN? I dont think your pfSense box will sync from someone on the lan…

If I had to guess, maybe 0.1% of the users who would even want to use that feature, would use it in its current form. The other 99.9% would want it based on group membership. So I think it would make sense for the platform in general to move in that direction, not just for any specific user's sake. But, I'm just guessing here.

As dotdash says, almost everyone will recognize "BSD firewall". I tell companies we have a pfSense box (and sometimes even m0n0wall) and they're like "what?". I have yet to meet someone that knows what they are. I tell them it's a BSD firewall and they say "ohh, ok".

A few examples just so you know what kind of feature I'm looking for: OpenNop and WANProxy

The tftp proxy is used for internal devices to connect to external tftp servers. Typically when you have idiot voip phone vendors and your phones need to tftp their configs/firmware. In my experience, you turn it on and it works. For your situation, I would think you could just create a port forward on 69/udp to your internal server.