SOLVED (kind of)…

It would appear I still had some pfBlocker configuration settings in my backed up xml file. Those were causing the issue. I still see the multicast message so as suspected its unrelated. Manual removal of all pfBlocker references in the xml and restore seems to have worked.

Then you need the rule I mentioned by negate the policy routing for the modem IPs, you're forcing traffic to the modems out the gateway group.

Check if configured dns is working on your pfsense and if you can browse files.pfsense.org.

http://www.freebsd.org/cgi/man.cgi?query=pfctl&apropos=0&sektion=0&manpath=FreeBSD+8.1-RELEASE&arch=default&format=html

@luke240778:

The last one i got in the US for $179, here it will cost around $700.

Ouch!  :o

Steve

As far as passing packets, the two are comparable. Our web interface will be a bit slower on hardware of that spec, just a lot more things going on, we have protections from attacks against the web interface that m0n0wall doesn't have, amongst other differences. If you have a busy dashboard, it'll really hammer a box that slow, especially if you show the traffic graphs on the dashboard. Everything else is much less difference. Unless it's something you're constantly in making changes, it wouldn't be a big enough difference for that to be a factor.

When the DNS forwarder is enabled, it puts 127.0.0.1 in there automatically so name resolution from the firewall itself uses the performance benefits and local caching of the DNS forwarder. You can check the box under System>General Setup if you don't want it to do that, but you usually want the improved performance of the DNS forwarder (127.0.0.1).

Thanks for the direction.
I think I put it in the right place.

Try to set this on the command line:

sysctl hw.acpi.handle_reboot=0

Then see if it can reboot.

If that works, you can add that as a system tunable under System > Advanced on the Tunables tab.

These kind of issues are almost always ACPI issues as others have mentioned. Update BIOS, toggle ACPI options in the BIOS, etc, to see if you can find a config that works.

you should use a vpn connection, start vpn from vpn->pptp , create a user list, on client with xp instead ppoe yo should create vpn connection when is asking for ip you need to enter exteriour ip form your pfsense (or can be made with dns if is dinamyc) after enter user and pasw , create new rule from firewall on pfsense to start internet sharing trough vpn or other other options,i've done this and is working fine, good luck

does your modem support pptp passthrough? is it enabled?

Any answer ?

Regards

At 4 Km, with a signal level between -60dBm / -65dBm and a Noise floor arround -90dbm your link must work OK

Using MCS15, with a 20Mhz Channel width, you get 130mbps, so for your 20mbps pipe it must perform OK.

I have done some tests using MCS10 at 20Mhz channel width (39mbps), with Nanobridge, and it can pass 20mps without problem.

http://dl.ubnt.com/UBNT-MIMO_Data_Rates_2.pdf

Yes, you will need to create a bridge between both pfsense to simulate a local config scenario

carp checks and sync transfers a lot of packages between firewalls, make some tests to see if this setup will not fill up your link between pfsenses.

If you are using vmware, this post may be usefull
http://forum.pfsense.org/index.php/topic,45093.0.html

The new speedtouch modem don't seem to be working that well with pfsense config. What you could try with the speedtouch en pfsense is the following. (not a very nice solution but probably works!)

Example settings!
1. Make the speedtouch your WAN connection just as it would normally do. WAN has public / LAN is fixed 192.168.1.1
2. Add an exposed host in your speedtouch: 192.168.1.254
3. At the WAN of the pfsense enter a static IP 192.168.1.254 /24 with gateway 192.168.1.1

If the speedtouch has no exposed host search for NAT or DMZ and make sure all traffic is forwarded to 192.168.1.254

This way your pfsense should be able to handle all firewall settings but be aware that due to the NAT in the speedtouch not all incomming traffic to the pfsense will work without problems. I mean when entering a NAT rule in the pfsense.

Please link to the bug or explain the problem. IMO 2.0.1 is just as light weight as 1.2.3, maybe a little more, but still not that much.
There are many others including myself that put scheduled rules in place. You just have to remember that you have to think of scheduled rules in kind of the opposite of what you would expect. Rule placement is just as important as the rule.

GNS3 - it will make your socks rock

@luke240778:

Ok, so by embedded it is not like DD-WRT that can be embedded on alot of normal routers?

No, image size and processor architecture are completely different from wifi routers to i386 machines.

never mind… found my answer...

http://doc.pfsense.org/index.php/DMA_and_LBA_Errors