You have to setup NAT before you can ping or do anything else with a Proxy ARP VIP. Use CARP if you must have a pingable VIP without NAT.

As I said, not something a lot of people need.  ;D My last comment in #8 explains why it won't be done for 2.0. You can use sticky connections to avoid the breakage, and alternatively you can easily modify the source to kill all states on every status change which sounds like probably what you want. Or put any command in there you want, kill only states for specific IPs, lots of possibilities.

It started working again since my last reboot, so rebooted again just now to get it to the problomatic state. This is what I get in the system logs regarding apinger: Sep 3 06:22:42 apinger: ALARM: 8.8.8.8(8.8.8.8) *** down *** Sep 3 06:22:42 apinger: ALARM: 8.8.4.4(8.8.4.4) *** down *** Sep 3 06:22:53 apinger: Error while starting command. Sep 3 06:22:53 apinger: command (/usr/bin/touch /tmp/filter_dirty) exited with status: 1

Cool.

@anthony0975: What is the best way around this?  Can PFsense somehow group both WAN and WAN2 into one Zone so I can just select the zone instead of WAN or WAN2?  I dont think bridging will accomplish this?  Or do I just need to double up on every single rule and have one applied to the WAN interface and the other to WAN2 On 1.2.3 you'd have to double up the rules. On 2.0 you can setup an interface group and manage them together.

ahhhhh so if these modems have routing functionality built in, could I disable dhcp on both of them, assign them unique statics on different subnets, i.e modem1: 192.168.80.1 and modem2:192.168.81.1 and then plug them both into a dumb switch and plug it into my wan interface? If not, i'm going to have to slap another nic card in this box… can I slap another nic into pfsense without re-installing? -m

Submicron, Thanks for that information, it shed some light on the subject… Cheers..  ;D

I posted another topic on this new "side-effect" I'm experiencing. Twice now I've started getting this message: kernel: arplookup x.x.x.41 failed: host is not on local network And my second subnet becomes inaccessable via the rules I've provided directly to the public IP's on the servers. However NAT rules still work. Any thoughts on this? The first time I did it, I fiddled with the DMZ stuff, unbridged, rebridged, rebooted, and it worked, this time it won't start working at all.

FreeBSD doesn't support routing metrics in that way, it would be nice if it did. You might also want to look into running a dynamic routing protocol like OSPF to exchange routes. That does support metrics.

@jimp: 1: GRE would have the lowest overhead, but wouldn't be encrypted. OpenVPN would offer the best of both worlds, but would have some overhead. 2: Simple policy routing will do. Have a rule that passes out from your LAN to * on http/https with no gateway set, and a rule underneath that catches the rest and passes out anything else to the gateway for the VPN (If you assign an OpenVPN instance as an interface you can create a gateway for the other end and use it in policy routing, GRE may allow the same) Two more things: do L2TP and PPTP have the same capabilities as OpenVPN (i.e. can be assigned as an interface, be used with policy routing, etc.), because should I not just use GRE but a VPN, I'd rather use L2TP and PPTP because Mac OS X supports these out of the box, and I try to use as few different modules as possible, because the more there are, the more potentially unexpected interactions and side effects. How stable is 2.0 in the mean time? In particular, what I'm interested in is if I should be able to upgrade REMOTELY from whatever beta (4?) we have now to the final release, because I can't ship the unit back and forth to a colocation provider somewhere half across the US just to do a software upgrade. So if the upgrade mechanism is stable and robust enough, and the configuration is forward compatible, I can start working with pfSense. Otherwise I'll have to wait until whenever these two conditions are met.

I use OSPF to handle redundant OpenVPN connections over multi-wan to ensure I can connect to some locations. It works really well. I wouldn't let the beta tag on that package fool you.

Just double check you NAT port forward settings, something is missconfigured. Interface should be WAN External Addr should be Interface Addr Protocol should be TCP External port range should be 80 or http NAT IP should be 172.23.2.1 Local port should be http or 80 Now check you Firewall rule: Action should be pass Interface should be WAN Protocol should be TCP Source should be any Destination should be Single Host or alias and 172.23.2.1 Destination port range should be http or 80 Gateway should be default By the way what is your DynDNS, I can check to see if your AP is in fact accessible from here.

I haven't seen it work yet, but you might start a thread on the 2.0 board asking if anyone else has.

thnx for the kind respond. yes bro i know this also. i have 2 router for my two connection. but problem is when we try to setup multi wan on pfsense 1.2.3 version it worked only 2 days. then when we try to setup multiwan on alpha 2.0. we couldnt manage it. because its seems very different from 1.2.3. so please it would be great help if someone can guide us. or give us a link for help. thank you

Thanks for the answer I was looking (and hoping) for. I will also look at the LAN addressing as advised. I have just downloaded the ISO image and will fire it up under VirtualBox before committing to the real hardware. Thanks again. David Goadby, North Wales, UK

Jimp: I added a rule as you suggested and it worked. Thank you very much.