Thanks that is what I am using now, 12+ hours with no issues.

Anyone know what the type of "other" would be used for?

Ok after more testing and troubleshooting.  Reseting the states will cause the traffic to stop going to that host.

Is there anyway to force this to happen when one of the servers goes offline?  Or when you remove one from the pool?

Yes it did. The problem was that I used the same network range in IPCop. I tried the same in pfSense. After changing both to a different network rage both openVPN Services were running.

Thank you very much for your help. It helped me a lot.

Vielen Dank Nachtfalke :)

Thank you to all

I had faulty setup concerning openvpn interface. And that why dhcpd was shut all the time and refused to start itself or by manually.
After i corrected setup then dhcp was started by itself.

@cmb: thank you i didn't know the location for the dhcpd or other services
@wallabybob & GruensFroeschli: I put that rule for optional networks, thank you for your advice.

After combing the forums I found this link.  I believe this is the exact problem I am having…
http://forum.pfsense.org/index.php/topic,35264.0.html

Thanks to everyone for the feedback.

Hewdy,
For inbound load balancing you just create NAT port map on each wan interface tab, no need for a group although groups should make it easier to manage the NAT/rules stuff. (For testing just add NAT map on each wan interface to see it work then play with interface groups, etc.)

For outbound load balance you got to system-routing then groups & create a new one with each WAN. If they are same tier they load balance, if not then they failover in order. Then you edit he default LAN rule and select the multi-wan group you created under Gateway section by clicking the Advanced button next to it.
Bill

cache management allows you to set a default, that combined with rotating logs out ever so often, I can't imagine you'd fill up the hdd..

Some commits but still not running right, see below link.

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

It uses dd to make the update. What about packages? I don't tried to install a package, but think that with this method the packages don't survive an firmware update.

But as I already say, maybe i'm doing it wrong.

I had helluva time with PPPoE in 2.0 but finally figured it all out:
http://forum.pfsense.org/index.php/topic,35475.msg183559.html#msg183559
I suspect the config files the admin writes are F'd up with stray/corrupt settings so the daemon freaks & gives odd logging.  Once it does it I've had to start over as no amount of changing settings in existing PPP profiles seemed to help. Plus it seemed once one was messed up (I have 3 wans, 2 are PPPoE other is static) none worked right.  The 1st few times it happened the way I ended up 'fixing' was reinstalling pfsense fresh (PITFA for sure) but later I found deleting & creating over after reboot (as described in above post) did the trick for me. YMMV of course, just sharing what I found over many many hours of frustration.

I've had it happen on nano & full so doesn't seem restricted to just one build.
Bill

Hi,
I noticed the nano/embedded version takes what seems forever to boot. If you watch console via serial you'll see it is waiting like 20 or 30 seconds (heck maybe it is only 10 seconds but seems like eternity lol) for you to select a slice before it eventually chooses the last working one then moves on. Then there is another point where it waits like 3-5 seconds for you to press a key for something else. Then it has to detect all your hardware & sometimes that takes awhile. (I disabled stuff in BIOS i don't need like sound & USB but not sure what your system supports)  I also noticed if you have an interface set to DHCP it but no DHCP server attached to it then it can hang there for awhile too.

If you really wanted to know what was going on hook null modem serial cable & watch it boot (assuming your box has serial port).  From the moment you tell it to reboot you can watch it shutdown then come back up & see what is taking so long.
Bill

Donne-moi un retour si sa fonctionne ou non de ton coté ! ;D

(Give me back if it works or not)

All VIPs should switch how things are right now. I haven't seen anyone else (with a proper setup) lately see CARP VIPs which are not all failing as a group.

There isn't a way to route traffic over the sync interface that way.

I just tried on my CARP VM pair and if I disconnect an interface on the master, all of the VIPs fail at once to the backup box.

@ermal:

It is at captive portal configuration page not vouchers one.

Is it the 'Idle Timeout'?

hi onhel,

i know, it all should be working now, i mean is not rocket science :P

here's the screen shot of the diagnostic and on the firewall, after enable login i could only find one package pass

diagnostic.png
diagnostic.png_thumb
firewall.png
firewall.png_thumb

Ive been saving from the ppps page then going to the WAN page and saving there also…  According to the ppp logs page it seems to be working but now Im not so sure.

side note-
Curious if you could post what you get running ifconfig...  Ive got an issue Ive been trying to run down for weeks on my mlppp connection.

Thanks!

Hi,

I just noticed that igmpproxy is not running on my box. There was no PPPoE reset, no log messages, no coredump.
How can I help you to track this issue?

Regards
Christof

@rcfa:

@gloomrider:

A Prolific USB/serial converter is less that $15US.  Serial console is not a "stumbling block".  You can install PC-BSD on a laptop (make it dual boot with existing Windows) and you'll be able to mount the CF card right on your laptop.

Being able to see boot time messages when working with beta software is a must, IMHO.

I'm using a Mac, not a PC :P

Anyway, the point is, if nanoBSD wouldn't BLINDLY turn off console (VGA+keyboard) support in systems that offer video and keyboard support (like the Lanner device I'm using), we wouldn't have that issue.
I have a screen and a keyboard attached to my "embedded" device, with a break-out cable that I can remove when everything is working smoothly.

In the age of plug-and-play drivers, it really shouldn't be that hard to see if keyboard and video drivers load successfully and to ONLY DISABLE VIDEO AND KEYBOARD IF THESE DRIVERS DO NOT LOAD properly.
That should amount to a few lines of code plus a conditional, yet it would solve a lot of headache.

Why is it, that a simple suggestion for improvement meets that much resistance? Aren't we here to try in whatever way we can to make this a better system? Or are we here to defend he status quo and prove that we're "right"?

Perhaps the central issue here is the target user group for pfSense.  It's probably much more than the average home user needs.  We agree that the average home user wouldn't have a clue about Prolific dongles and terminal emulators.  But pfSense is really for the small to medium size enterprise space.  As others in this thread have pointed out, serial console ports are common on ethernet switch gear.  Usually the serial port is used for initial setup only.  Those of us that have to go on site and setup instances of pfSense would hate to have to schlep a monitor, keyboard & mouse into a comm closet.

Regarding UFS access with your mac, you might want to look here: http://osxbook.com/software/unixfs

Keep in mind that FreeBSD is a server OS.  Those that deal with server-class operating systems are used to terminal emulation and command-line.  It's how we get things done.

If I understand everything that I've read here about the Lanner gear and pfSense, the serial console works and can be used to initially configure pfSense.  It's probably not useful to debate the topic, "but this is 2011, serial is so 20th century, why should I have to deal with it?"  I'm certain that on-board video is not being disabled just to foist serial communication upon those who dislike it.  For lightweight, embedded boxes whose primary purpose is moving packets in and out of ethernet interfaces, on-board video is superfluous and a waste of valuable system resources IMHO.

The issues that you're having with initial configuration can be easily solved with a Prolific serial/USB adapter and free terminal software (look for the program "screen" on your mac.  It's CLI, sorry).  I suspect the linkage between nanobsd and initial serial setup will be around for some time to come.  But I (and no doubt many others) would be curious to know if your setup was successful once you perform the initial setup through serial and CLI.

Good luck!