All kernels (even Dev) are SMP on 2.0.

There is no longer any benefit to loading a uniprocessor kernel (Mentioned a little here but also in more detail by me around the forum).

I've had some issues with the dev kernel in certain setups as well but it does a lot more strict locking checking and reporting, which is what you appear to have hit here.

We have enough debug info in the stock kernel these days that the full dev kernel isn't quite as necessary on its own, but still useful in rare cases.

Thanks I will discuss it with him. Thanks so much for the help!

Chris

@dmitche:

Untangle drops all VLAN tags when it rebuilds the packet so I cannot pass and tags to/through it :(

create three new vlans, apply it on pfsense and untagle port

then you can setup this:

workstation –--- vlan19 ------ untagle bridge ----- vlan119 pfsense
workstation ----- vlan20 ------ untagle bridge ----- vlan120 pfsense
workstation ----- vlan30 ------ untagle bridge ----- vlan130 pfsense

assign 10.10.30.1/24 on vlan 130 at pfsense
assign 10.10.20.1/24 on vlan 120 at pfsense
assign 10.10.19.1/24 on vlan 119 at pfsense

The last IPsec config, if deleted, would not be removed from the secondary in 2.0. That's fixed in 2.0.1.

CARP and multi-WAN are two separate, unrelated things. Though you could hack apinger's config to run a custom script that disables CARP when a WAN goes down and triggers a filter reload, and another one that re-enables it + a filter reload when a WAN comes back up.

you may need to split your questions, I can't see carp issues, just pptp issues

To change xml, backup your config first, got to console, remove duplicated entries from /conf/config.xml and reboot.

could be done but not supported officially

http://forum.pfsense.org/index.php/topic,40917.0.html

cmb,

I went back to the book, and learned quite a bit. I was misunderstanding the options in the rules setup, thank you for giving me a direction to look in, I have it working now.

In the end I had a look through the firewall logs and saw the 'easy setup' option to create an allow rule and followed the syntax. I didn't realize the feature was there, I'll remember next time.

Answering only the first, do you have set these kind of rules to your vlan's?
from vlan-subnet (or any) to any

If yes then problem is your rule sets. you can create such alias called localnetworks and add all local networks to that alias.
Then add this rule to your vlans

block from vlan subnet (or any) to "local networks" and make sure that this rule is above any other rule.

Has to be static and all on the same subnet so that won't work for stateful failover. You can do CARP only on your internal interface, and just lose all your states when you fail over. That's what I do on one of my WANs at home where I can't get static IPs, have two DHCP IPs and just live with losing states when it fails over.

More info.

I have another NAT mapping, identical to the 443, but this is for port 25.  It works perfectly.

So I tried to change the NAT like so:

WAN2    TCP    *    *    IP3    444 (HTTPS)    PDC    443 (HTTPS)

And that works perfectly.  Accessing it on http://IP3:444/ works always.

Changing it to:

WAN2    TCP    *    *    IP3    443 (HTTPS)    OTHER_SERVER    443 (HTTPS)

Causes the same issues - hence it is not the destination server at fault.

The other mapping I have is also identical to the 443, but for port 80.  This one works too.

As I said, loading the NAT on IP1 (the WAN2 real IP) works to 443.

State table entry after a telnet that connected/disconnected looks like this:

tcp PDC:443 <- IP3:443 <- 96.55.212.111:64668 ESTABLISHED:ESTABLISHED
tcp 96.55.212.111:64668 -> PDC:443 ESTABLISHED:ESTABLISHED

Any help would be appreciated.

That might work, but i think the problem is in basics of networking gateway has to be on same network. -> with that said you can't use CARP virtual ip's

You can use PARP or IP alias version of virtual ip

It's for security and performance reasons. Detailed explanation in http://pfsense.org/book

Update, I finally got the ISP out there and it was an issue on their side so all is well now.  Thanks again!

Okay from my testing, it seems that this works just fine:

/sbin/sysctl net.inet.carp.allow=0

or set to 1 to re-enable.

Create another vlan and assign it to a sync interface.

Then assign this vlan to a sync interface and allow all traffic on it.

I preffer using vlans to do not have many cables plugged on my firewall.