@cmb:

You're not passing ICMP with that ruleset. Your public IP isn't responding to ICMP either (pulled your IP from where you're accessing the forum, it matches the subnet of one of the gateways in your config so I presume that's it).

OMG I am so sorry, I cannot believe that I have been pinging the gateways! Something so simple… wow never say never, Thanks.

Hahaha at least I memorized The Definitive Guide to pfSense

If you really want to put some serious effort into it, we'd love to have a great automated test suite. Just a matter of that's a huge amount of work to do in a manner that tests a wide range of functionality. You could setup a test environment with a number of installs that are using pretty much every feature, and write a set of tests to check all that functionality. You'll be busy for a long time.  ;D

Thanks for the clarification.

Now whatever architecture I come up with, I am always going to have routers between the clients and the captive portal. From looking at the captive portal configuration page, I figured disabling MAC filtering would allow pfsense to support this setup.

Considering our case is not a paying internet solution, but rather a setup to offer separate guest wifi internet access in our customers' offices, I'm not really worried about people sharing logins, as they wouldn't be able to log in simultaneously with the same login anyway, provided I enable 'Disable concurrent logins'. Am I correct in saying that?

Thanks

It was an issue with the bce driver we tried to update. The driver apparently didn't work, so it was rolled back. The next new snapshot should be OK.

That first one just means that sysctl doesn't exist on your system. Apparently that one is i386-only, so it doesn't matter on yours. It can be safely ignored.

The latter two messages have been reported previously, there is an open ticket for one or both of those, but we're aware of them both.

That would take quite a bit of extra logic (prone to extra breakage!) to pull off, if it's even possible.

Most people have always-on WANs so it's beneficial to query them all at once. 3G is the obvious exception to that, and I think someone already has a feature/todo ticket open for 2.1 so we can have a more sensible dial-on-demand mode for 3G WANs since not just DNS but the connection monitoring traffic can add up over some time. People without unlimited data plans might be surprised at the usage.

The monitor IP is updated every second. You could change the interval if you want, but it may cause other issues. Edit /etc/inc/gwlb.inc and find the line for the interval under the default target. Then edit/save a gateway to resart apinger.

Did you upgrade your firmware between there?

The old method of counting processes was undercounting. We changed recently to a more precise count, that includes not just user space processes but also kernel/system threads.

@mromero:

ALWAYS appears to be weekend hell for updates  - especially when the in-house D.J. releases a new track ::)

Sounds like a personal swipe directed at me, eh?

Thanks for that. I tried rebuilding with yesterdays release and had the same issue so rolled back to the release from the 7th which fixed the problem.

@heavy1metal:

I'm curious about your setup if you're able to share, love the LCD heads up display.

Easy… I was using a package called LCDProc... the problem is that package is not updated and I had to compile the latest version in order to get the specific driver for my LCD panel... then I had to update the package to let choose/use the new driver...

finally I found out that the package didn't care about the size of the LCD panel, but was using only a 16x2 fixed layout... so I worked again a bit on the package and made the screen size used (my panel is 20x4 chars)

Now every time I update pfSense I need to update manually the package uploading the correct files, until the changes I made will be merged in the "distribution release" of pfSense...

The program "fetch" is on the system by default and it can do much of what wget does as well. For most people, fetch is enough so adding wget isn't necessary. (And curl is there, too, depending on what packages you have installed)

1:1 NAT on WAN wouldn't help for that.

You need to be on manual outbound NAT, and have an outbound NAT rule (or maybe 1:1) on LAN in order to translate in the way you want.

Are you doing any traffic shaping?

hmm, just misreading some packet traces in the end. I mistook the monitoring probes for browsers requests and failed to spot that the web servers were not sending responses back via the load balancer, but direct to the browser via the main gateway for the subnet.

Okay, everybody is running.

Thanks to all who were able to collaborate.

That's odd. What NIC are you using for LAN?

Steve