applied patch manually and tried, works, thanks

Sure. I guess it pays to not just look at the screen shots.

@Reiner030:

and the client was running yesterday on master and slave in parallel so they kick themselfes every some minutes…
Today after longer downtime now  it's running/connected only on slave so that "normal" routing is not possible :(

::) aargh … forget yesterday that "interface" must not be the interface "name" itself (then it bounds both server/client on each fw directly)
  but bound on both sides to the alias/the CARP IP ^^ ... so now it works again as expected.

Can you describe your setup and paste radvd.conf and dhcpd6 config files?

And what is your mask, a /23 would be like that your gateway is 236.1 and your interface is 237.109

What do you mean you can not access your 237.109 IP from internet?

What does the first couple of octets look like if starts with 10.x.x.x or 192.168.x.x or 172.16-31 then your behind a NAT.  And no you would not be able to directly access from the internet say 192.168.237.109 address.

Confirmed fixed :)

Big thanks to everyone who worked on it.

That seemed to fix it, as it seems atm.. your awesome.. Thanks you for your help.. :)

@Rickinfl:

the LAN side goes from the LAN card in pfSense to the 8 port switch which feeds all the other computers via CAT5 cable.

The 3 other computers (My Computer, Mediawiki and PS3mediaserver) should all be able to talk to each other without pfSense or internet at all. So you need to get that to work - disconnect the pfSense LAN cable from the switch, then get the 3 computers working locally on the switch.
Once that is done, then connect pfSense LAN to the switch again - if a problem happens then we can try to help with it.
I guess the switch is a "plain ordinary" unmanaged switch, with no VLANs, no MAC filtering?
(If you have a fancy switch then maybe something was set in that that causes your local LAN issues)

ok I figured out I need to add a pass rule for the wireless lan.

@NOYB:

Ah it see.

Hmmm, interesting.

Perhaps browse not fully refreshed?

DUH.  Thank you!  Yes, that was issue.  I hadn't forced Firefox to refresh.

Defaults are good in those fields, but it is better to have it configurable for those that need it.
I think that while you cannot put things there on purpose, packets still get there, so why not have the ability to control it?

I had the same issue. Poking around the filesystem I discovered that you can access your reports by appending index.html to the URL, seems that whatever web server is running in pfsense does not recognize index.html as a default page.

Try this:

…./bandwidthd/index.html

Mark.

@jimp:

Do you get an IP if you're bridging and fill in the server bridge dhcp start/end?

If you do, then check your actual DHCP sever logs to see if it's being rejected for some reason there.

Make sure you read/understand the note under the bridge interface selector.

I thought I tried and read everything ::)

Thank you!
I didn't create the bridge interface necessary for the connection… Now I'm afraid to open a new topic for another bridging thing I keep failing at. I'll just keep messing with that one :P

For other people running into this; Create the bridge!
If you are running into the error:

OpenVPN Route: OpenVPN needs a gateway parameter for a --route option and no default was specified OpenVPN Route: Failed to parse/resolve route for host network: ***

Define the DHCP start and end options.

//Edit:
Is it normal that interfaces with IP set to "None" have their own undeletable gateway and spawn syslog messages?

Feb 27 21:09:50 php: : rc.newwanip: Failed to update opt10 IP, restarting... Feb 27 21:09:50 php: : rc.newwanip: on (IP address: ) (interface: opt10) (real interface: ovpns1). Feb 27 21:09:50 php: : rc.newwanip: Informational is starting ovpns1.

//Edit2:
Also, when applying these settings, a random CARP VIP goes down:

Feb 27 21:26:41 kernel: opt2_vip1: link state changed to DOWN Feb 27 21:26:41 kernel: opt2_vip1: INIT -> BACKUP Feb 27 21:26:41 kernel: opt2_vip1: link state changed to DOWN

The first time I configured the OpenVPN bridging, I thought it could have been because I accidentally had the bridged interface in OpenVPN Settings configured to the interface opt2 for a minute. The second time though, I had left the OpenVPN settings bridged to the correct network and was extra cautious with creating the bridges but the same VIP still went down. There is no special reason for that interfaces VIP to be affected, I have other interfaces configured exactly the same. The only thing I can think of is that this is VIP1.
The solution was to 'edit' the settings for opt2, change nothing and apply settings.

The error seems to come from syncing the configuration to the other firewall:

Feb 27 21:26:41 kernel: opt2_vip1: link state changed to DOWN Feb 27 21:26:41 kernel: opt2_vip1: INIT -> BACKUP Feb 27 21:26:41 kernel: opt2_vip1: link state changed to DOWN Feb 27 21:26:41 php: : Beginning XMLRPC sync to https://172.20.1.2:9180. Feb 27 21:26:38 check_reload_status: Syncing firewall Feb 27 21:19:20 php: : Filter sync successfully completed with https://172.20.1.2:9180. Feb 27 21:19:12 php: : XMLRPC sync successfully completed with https://172.20.1.2:9180.

Firewall 2 on 172.20.1.2 did not have the interface configuration yet at that time. When fixing the issue by 'editing' the opt2 interface, the correct configuration was already applied to the second firewall.

Funny thing is that FW1 shows the CARP IP to be down and generates a notification of a failing sync but FW2 doesn't even have a log entry of it.

i connected USB HDD and mounted as /var/squid and everything works well but i get one error in system log

squid[50178]: Failed to verify one of the swap directories, Check cache.log for details. Run 'squid -z' to create swap directories if needed, or if running Squid for the first time.

I'm thinking the reject method mentioned in that other thread (and http://redmine.pfsense.org/issues/2704 ) are a good long-term solution for this, even if it's not a general solution.

My cable modem makes multi-wan pretty useless even with an alternate monitor IP when it's down that way because it renews the private IP every 30 seconds which then restarts apinger every 30 seconds which isn't long enough for it to realize the WAN is down and to stop using it. Even with another monitor IP it will still fail in many cases, but it has a better chance of working with the alternate monitor IP. It just depends on how your modem handles the lease.

I'm not sure that rejecting the lease will actually help but I haven't had a chance to try it just yet.