Alain has helped me. The cause is a misconfiguration in cisco. The line "ip rip authentication key-chain chain cisco" must be "ip rip authentication key-chain cisco" Louis14

What you're describing is impossible at a network level. DNS has no relevance in how a connection is made, it's simply used to resolve the hostname to an IP, and then the request is made to the resulting IP. Hence making the request direct to an IP, and to a FQDN that resolves to the same IP, is exactly the same. The only exception to that would be with HTTP using host headers, but that would generally be the opposite scenario, hostname working and IP not working. Regardless, doesn't have anything to do with the firewall.

Thanks Jimp, you're right, that MAC address turns out to be the VIP of the firewall cluster that acts as the default gateway on the WAN interface of the PF 1.2.3 cluster. What I dont understand though is that the route back to node A is via the PF 2.0.1 box, this route is visible in the routing table, and the arp table shows the correct MAC associated with this 2.0.1 box. So the 1.2.3 systems seem to be ignoring the routing table entry for this network and just forwarding to the default. I'd put that down to some wierdness in PF except we have another network to anotehr router where this behaviour doesnt occur (ie it just works as expected). I've disabled reply-to anyway. no change as yet. I'll try and bounce the primary out of hours and see if that helps (but not hopeful, I did a bounce on the backup last night and routed some traffic through there - no effect). In the mean time, looks like as this isnt a CARP issue this is probably posted in the wrong place, any way to get it moved? Mx

(Very quiet forum section, few responders? Oh well, I will just talk to myself and think out loud.) It looks like merging multiple router functions into a single box should be theoretically possible, though it is unclear if a pfSense virtual VLAN can send out data and have it picked up by another pfSense virtual VLAN. For the two PPPoE child routers: Don't need DHCP, since the parent router will be the only receiver Don't need NAT, since the parent router will be the only receiver Firewall rules must be explicitly defined rather than using "any" LAN side is a VLAN circuit only, no gateway groups defined here The parent router acts normal like a default configured pfSense, and uses DHCP and NAT. Default-config WAN is not used, replaced by load balanced group Don't firewall block data thru 192.168.x.x since that is required Firewall rules must be explicitly defined rather than using "any" So the order of construction appears to be: 1. Default install of pfSense creates the parent router Set initial WAN to unused temporary VLAN X 2. Create first child router and rules, using unwired VLAN A 3. Chreate second child router and rules, using unwired VLAN B 4. Build the gateway group with unwired VLAN A and VLAN B as members 5. Disable the default WAN interface, change rules to point to gateway group

Add a matching phase 2. IPsec doesn't route, traffic has to match the P2 local+remote.

That rule is correct to send all that traffic out via that route. The fact that makes it stop working means either that Internet connection isn't functional, or maybe you're using manual outbound NAT and don't have NAT properly configured for that WAN interface.

@heper: what version are you running ? the problem you refer to appears to have been fixed a long time ago Reversed to 1.2.3 from 2.0.1 due to high CPU issue. See http://forum.pfsense.org/index.php/topic,41647.0.html Even got back a bonus with 1.2.3 and failover, now I can use 4(or more) ping targets per WAN link for determination of WAN link status. Not possible in 2.0.x. But my current issue is resolved on this topic with the help of this: http://forum.pfsense.org/index.php/topic,31253.0.html http://www.globalmarinenet.com/downloads/wxa/apinger Now I'm trying to find out why pfSense 1.2.3 is using my NAT rules to redirect me to my own application running @ port 443 when I try to access any https URL on the web when my secondary WAN is down(maybe even the same if my primary WAN is down, but I don't know for now) when I'm browsing the web from my LAN.

That was the ticket man thanks. I was a little leery about the update since I did some beta updates before and they broke things but this seems to have solved it. I appreciate the reply.

No site-to-site for me–I am simply running pfSense with PPTP VPN for remote access to the office on it, nothing special in that regard.  Good luck with the site-to-site setup.  I know some people who have it running, and they swear by it, but I've not played around with that feature yet.

Thank you for the answer. My provider is using IPoA, but pfSense doesn't support it currently (AFAIK). I'll must use a double nat and it will be a real pain to maintain. I can't find any word on this limitation in the wiki nor in the (non-exhaustive) features list, so I can't put a link as reference.

Alright. Thanks for the lead. :)

@dhatz: Striker have you been doing VPN bonding with ZS for a long time? How has is worked for you? I've been doing it for like a week or so. In comparison to load balancing bandwidth gets reduced by round about 15%, which is because of OpenVPN's overhead I assume…  :- But apart from that, everything works out pretty well. Websites which require log-ins and check for the IP addresses used to log me out automatically while using simple load balancing. Yeah, I don't have that problem anymore.

Apparently this was something wrong on the ISP side of things.  Having now spent a lot of time talking to them and them extracting more time and money out of me, all is working as intended.  I'm not totally sure what's going on still but for now I am ok with that.