Apparently when a new interface is added (even from an existing card), a reboot is required.  Seems a little silly when you should be able to accomplish the same thing via restarting networking and routing..

Does anyone know if the same holds true when you add a new vlan?  Or can you simply do an ifconfig <vlan>up?

Thanks,</vlan>

CARP is designed to protect you against hardware failures. Nothing can save you from a completely incompetent ISP.
I don't think there is any solution other than getting a new provider.

still not getting it working

i´ll add some screenshots

i have tried with and without portforwarding(and removed 1:1) that doesent work eather

i´m i missing something here?

do i need to do something on the "nat outbound" rule?
should i see the external adress when typing "arp -a" ?
i´m trying to connect from the outside on port 25,80,110 and i dont see any traffic at all comming with dest 195.x.x.x

edit3

edit4
tried again at work and it works like a charm there..must be something my isp is doing, maby sending me several vlans or something
/F

1to1.JPG
1to1.JPG_thumb
fw-rules.JPG
fw-rules.JPG_thumb
portforward.JPG_thumb
portforward.JPG

If all is fine are the master/slave states correct (the main system is master on all interfaces and the failoversystem is backup on all interfaces)?

PPPoE will only work on the original WAN interface, not on OPTs. If you have the option to get static IPs there I would rather use that instead of PPPoE.

IPSEC-failover is not possible.

For normal traffic just create a failoverpool at services>loadbalancer, type failover and enter the gateways in the order you want them to be used. Then reference this pool in your firewallrules.

@dotdash:

@garg_art2002:

On another note, do you have some pointers on why Virtual CARP IP would be more complex that Virtual ProxyARP IP's?

Mostly just me being paranoid, but CARP adds some broadcasts and has the same protocol number as VRRP. While CARP will reject VRRP packets, it is within the realm of possibility to interfere with your providers VRRP setup. Deleting CARP VIPs requires a reboot, where Proxy-ARP does not. It probably adds a tiny tiny extra bit of cpu load to the box also. Oh, and there's the additional work of adding a password and keeping the VHID's unique. Ok, the last two are pretty weak…

Thanks - This helps. Interference with providers' VRRP and reboot are serious (in that order) IMNO (in my newb opinon!).

Best regards.

All working…..

i Have two boxes configured with CARP ... all is working ....
the problems with OpenVPN stops when .. i Deleted all related OpenVPN on Master .
look , may master (first box ) was configured with openVPN when i decided to have an Carp solution (second box)

step by step i did:

Backup all data on OpenVPN config page (Ca.crt, server.key, server.crt, server.dh) and clean all fields. deleted server config on OpenVPN.. when all was clen in both boxes . reboot. with master box off i did all OpenVPN config on the slave box, then started master box and did config too. The config are exactly same.
in my Road-warriors clients i did a connection to 1194 TCP on the VIP address of WAN .
now my clients can connect in master or slave box, when master goes down connection are dropped and in seconds restablished. When master returns again, connections are dropped and reconnected .
No more errors connecting on the slave when master was off.

@slicknetaaron2:

I'm not an expert, but I did set this up on my own network.

Later on in the document that vichon linked to, it states:

For NAT portforwardings: NAT is applied before the Firewall rules.

NAT-Reflection does not work with 1:1 NAT
http://forum.pfsense.org/index.php?topic=7266.msg41244
quote:
You most likely need to setup split dns or add a port forward on top of the 1:1 nat to invoke reflection.  Reflection by default does not work with 1:1 nat's.    So your most likely resolving the public IP address which will not forward back across to the 1:1 server.

If you have problems with FTP and NAT:
http://forum.pfsense.org/index.php/topic,7096.0.html

Since you are using 1:1 NAT, according to this, NAT reflection will not work by default.

Does your webserver resolve on public DNS?  If so, here is what I did.  It seems pretty elegant to me.
(I don't have my pfSense box in front of me, so I'm going by memory here..)

If your webserver resolves to www.mydomain.com publicly…

Use the DNS forwarder in pfSense.  Your hosts must use your pfSense IP as their DNS and/or make sure DHCP distributes your pfSense IP for DNS addy. 
Add a rule that resolves www.mydomain.com to the LAN IP of the server. 
That way the public will use public DNS and resolve to your public 1:1 NAT address, and when you are on the LAN, it will resolve to the local LAN IP.  Neat, huh?

If you need to resolve the root domain [mydomain.com instead of www.mydomain.com] I think you may have to do some more advanced stuff [like having you own internal DNS server?] Not sure

For me, it was super easy to setup. Pretty self-explanatory.

Aaron

Aaron

This technique is called "split dns" and I would always prefer it over natreflection when possible. Resolving the mydomain.com is just as simply. Just add a second hostentry for this in your dns-forwarder.

thanks for advice, I will try this, but this is not as elegenat, i want my 4 hosts on DMZ to have public adresses configured. i treat NAT 1:1 as more complicated than my desired configuration.
My configuration is more elegant and simpler but unfortunatelly pfSense has problems with advanced routing (there is no routing option at all), it is rather advanced firewall and very simple router.
I wonder (will testing) if DMZ and WAN can use the same addreses and be NATed 1:1
i mean x.y.z 195 on DMZ nated to virtual IP x.yz.195 on WAN
this will be very sophisticated and complicated but it will look like my desired configuration for hosts in DMZ.

pfSense lack routing. You have no control on routing in pfSense but You can change routing in shell.
I tried to do my routing. IT support it, You can make any of routes I described using route command, even can control proxy ARP.
but one i cannot override:

this freeBSD do not accept default route gateway x.y.z.193 on WAN (le0)
when I insert route giving -interface le0 it shows "route: bad address: le0"
when I ommit interface i got strange route
0&0xc0a800002 link#3 UCS 0 0 le2
this route is wrong because use wrong interface and is difficult to alter or delete
but when I leave original default an only make change to it
route -d change 0.0.0.0. interface le0
i get
default            00:0c:29:8a:d1:f9  UGS        0        4    le0 (this is good, my gateway is on le0)
and it worked fine for few minutes (this is mac for le0 WAN interface) and then it hangs and i did not get the same result after restart
even using the same command

it looks like my configuration Is perfectly coorect buy freeBSD do not gives You full control on routing

the main problem is that my gateway is on WAN but its addres is covered by DMZ subnet
so setting this gateway as default implicit make default route on DMZ
using explicit WAN interface is not accepted by freeBSD
i think it is kind of BUG
i public this gateway using proxy ARP on WAN, so it should accept it !!!

but when i force freeBSD for correct route table i wonder what will the firewall do

Im not good in network configurationin BSD/linux
but maybe should make sophisticaed /etc/rc.conf to make  routes permanent
and avoid changes made by pfsense

and wait for 1.3 release
maybe they will fix problem with traffic shaper in bridge mode (does not work in 1.2)
so then i will just bridge WAN and DMZ
it is simplest way to get my configuration

Try reinstalling 1.2 with the SMP kernel.  Does this change the situation?

Do a tcpdump and run through wiresharks expert analyzer.

We are probably able to optimize this. Thanks for the report.

It should not bring down already established connections afaik and if it would do so it would only take 5 seconds as this is the interval that slbd checks the servers for availability and reintegrates them as available in the pool.

Use CARP since local services on pfSense cannot bind to PARP type VIP's.

I dont see any problem (using a similiar setup right now).

Thank you! Thank you! Thank you!

That small change fixed it.

did you check the log's? cz is verry strange.

Is it really likely would you want to set PPTP up on the IP of the machine, and not the VIP?

I'm sure in pretty much every case if you set it up on a clustered machine its going to be on the VIP, or else you loose access when the machines failover.

Ben