This is solved, and where actually surpricingly easy.

Added the VIP as static IP, next I created an NAT rule, where the source = the DMZ network, and the NAT address is = VIP.
Voila, solved. :)

Now ingoing traffic to both IPs is working, and client and dmz have different outgoing IP addresses. cooool  ;D

why not assign a static IP to the management interface of ESX so that you can always connect to ESX.

then configure your pfsense to boot first in ESX, and add a startup delay on the other VMs so that when they boot pfsense is already up?

Thank-you, Jim.  That was the issue - I needed to tighten up my NAT rule.

@mrzaz:

@vbman213:

Fixed: http://redmine.pfsense.org/issues/3075

Thanks!

I have just updated to the latest build (2.1-RC0 (i386) built on Tue Jul 9 23:03:10 EDT 2013" but still see
this problem when trying to remove "IP Alias" entries.

I get "This entry cannot be deleted because it is still referenced by at least one Gateway." when trying
to remove one IP Alias.   (I only have one primary IP defined in the WAN-interface .51 at end
and one VirtualIP "IP Alias"with .53 at the end. Is in same subnet as primary IP.

The "IP Alias" was created in an earlier build from June.

I was only doing some tests for a colleague and need to undefine the IP Alias as this IP
is normally used in another router and is temporary disconnected so I could do the test.
As long as this IP is now tied to pfSense it will answer ARPs and I will get an IP collision.

Dan Lundqvist
Stockholm, Sweden

I would recommend posting on the issue page @ http://redmine.pfsense.org/issues/3075

Binding the Alias to localhost worked a treat.  I read that you shouldn't bind it to the WAN interfaces because it'll cause an IP conflict,  I also noticed that Aliases bound on those interfaces don't sync over XMLRPC.  However, an Alias bound to localhost synchronizes as expected.

Thanks again for all your help.  This NAT/Other VIP stuff is much quicker to configure.

You can find the source of the net.link.ether.inet.carp_mac patch here:
https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_8_3/carp_correct_mac.diff
As far as I understand, it only changes the MAC-Address of outgoing ARP-Pakets so it doesn't solve the problem.

We managed to get around the problem by putting a linux box between the pfsense firewall and the router.
It has no ip configuration but a bridge(like a hub) and rewrites the mac-addresses of the outgoing packets.
The configuration looks something like this:

brctl addbr br0 brctl addif br0 eth0 eth1 eth2 ifconfig eth0 up ifconfig eth1 up ifconfig eth2 up ifconfig br0 up ifconfig eth0 0.0.0.0 promisc ifconfig eth1 0.0.0.0 promisc ifconfig eth2 0.0.0.0 promisc ebtables -t nat -A POSTROUTING -p IPv4 --ip-src <ip3>-j snat --to-src 00:00:5e:00:01:2d ebtables -t nat -A POSTROUTING -p IPv4 --ip-src <ip4>-j snat --to-src 00:00:5e:00:01:2e</ip4></ip3>

lHmm..
I suddenly realized the ISP told me to be sure that the vrrp routers could see each other using my network. So if stp blocks one port, vrrp will no see the other router. It is btw a Dell 3348.

Greetings,
Roger

You cannot do both NAT and routing. I does not work unless you are NATting to LAN and routing a completely separate IP block to say DMZ. Your ISP must route that separate IP block to an IP on you WAN block. Otherwise you are going to have to work through whatever NAT problem you have. Perhaps using the SIPProxy package?

Complete failover to the backup machine is controlled by net.inet.carp.preemt = 1, which is the default for PFSense as far as I know (at least on our 2.0.1 production machines).

So yes, should any CARP VIP lose link (or rather, should the backup machine stop receiving the heartbeat from the primary), the backup will bring up the VIPs on all interfaces.

I'm not quite sure what you're asking here, but an initial setup to get you started with CARP is demonstrated here: http://doc.pfsense.org/index.php/Configuring_pfSense_Hardware_Redundancy_(CARP)

System was up and running fine prior to 2.0.3 and test regularly for redundancy.

System is Multi WAN / Multi Lan with Carp syncing two systems.

Carp status was fine. Primary and secondary both reported normally.

I could ping my Lan address and PFsense WAN IP's with out drop.
After the WAN ip's. (IE: WAN gateway) packets start dropping for no reason.
I could get a good set of pings to the same address for a bit…then stop again.

Tested each WAN by it self with same results with both boxes up.
The only fix at the time was to remove one box from the cluster. (just a shut down....not disabling carp)

Well, it's not expiring even after 12h :)
whatever…

Apply Virtual IP on your WAN interface and policy based rules on your firewall?

nullifi, have you ever figured this out?

We have been struggling with sporadic failovers (master demotes itself) for over two years now on one cluster.
This never happens on any other cluster, just this particular one, and we can't seem to find out why. Both hosts run VMWare 4.1 with all MAS forgery, promiscuous mode, this NetReverseFiltering = 1. None of the other PFSense clusters on the two VMWares have this problem, just this one, so I think this may be PFSense/Config related rather than Layer 2, as the other boxes share the vswitch on VMWare.

Also, on the CARP status page, clicking "Disable" then "Enable" repairs it until it demotes itself again.

Any ideas?

I think you misunderstood me, but I believe the issue is the DSL modem.

Can you get into your DSL modem? Generally you can change the setting for it by browsing to the IP address that is the default gateway on the WAN for your DSL network.