Hey,   with 2.0.1 the NAT is not a problem anymore. If you still have the problem, maybe could be a "traffic shaping" queue. I mean, the CARP traffic can be dropped under heavy traffic, and this can bring to an inconsistent CARP status between the master and the slave box. I am not sure, I figure out that could be a traffic shaping problem today… this is my post: http://forum.pfsense.org/index.php/topic,45045.0.html Ciao, Michele

Hello, anyone that can pls confirm this? Now it's 3 days, 6h that the two firewalls are working and everything is going great! The problem was: WAN Interface: x.x.x.x/24 2 CARP VIPs (on 83) were: x.x.x.x/32 The question is: Can this misconfiguration bring to an inconsistent CARP status (half of VIPs Master on one firewall, the other half Master on the other firewall)? Thanks a lot, Michele

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