Thanks, I will continue my investigation, if I have any further information or questions I will get back to this topic.

Thanks

OK, I found the problem.

https://github.com/pfsense/pfsense/blob/master/src/etc/rc.filter_synchronize

A bunch of these lines:

$config_copy['nat']['outbound']['rule'][$x]['descr'] = remove_special_characters($config_copy['nat']['outbound']['rule'][$x]['descr']);

The function remove_special_characters strips out everything but a-z, A-Z, 0-9 _ - +

Should have maybe used the function htmlspecialchars instead to get special characters encoded instead of stripping them. Also having the xml in UTF-8 allows you to put a lot of international characters in the xml file.

Anyway, it's looks like it's been working like this for years.

I was able to reproduce both of those bugs. We've hit similar things in the past.

I created new issues for them:
Limiters: https://redmine.pfsense.org/issues/9468
ALTQ Shaper: https://redmine.pfsense.org/issues/9469

All changes that are synced.

check the clocks on both nodes

A 255.255.255.252 netmask is only a /30.

Please send the actual addresses in a chat. That makes zero sense and it's impossible to help you without knowing what they actually are.

As posted in other thread...

@Derelict Thanks for the tips. I got it to work. I didn't really understand what you meant, but I agreed it seemed like a NAT issue. I found a separate thread where you said the 'NAT Addresss" should be the VIP address. So, I made sure to change all the WAN1 and WAN2 mappings to the VIP addresses. (I tried this once in the past, but I didn't think it worked. I must have not refreshed it or something)

https://forum.netgate.com/topic/119782/solved-setup-manual-outbound-nat-section-in-pfsense-docs-unclear-to-me/4

Anyway, after using the VIP addresses in the NAT mappings, it fixed the WAN1 to be online at all times.

Thanks!

@Derelict Thanks for the tips. I got it to work. I didn't really understand what you meant, but I agreed it seemed like a NAT issue. I found a separate thread where you said the 'NAT Addresss" should be the VIP address. So, I made sure to change all the WAN1 and WAN2 mappings to the VIP addresses. (I tried this once in the past, but I didn't think it worked. I must have not refreshed it or something)

https://forum.netgate.com/topic/119782/solved-setup-manual-outbound-nat-section-in-pfsense-docs-unclear-to-me/4

Anyway, after using the VIP addresses in the NAT mappings, it fixed the WAN1 to be online at all times.

Thanks!

@Derelict thank you so much, have a nice day!

Success!

Tried it out live now.
Shutdown machine #1. Branch Office lost its connection to the Main Office for about 10 seconds. This is OpenVPN reconnecting.

After OpenVPN peer-to-peer reconnected.
Resolving from AD DNS works! TIL: So, multiple domain overrides is the way to go for internal name resolution in this scenario with AD DNSs.

Goal achieved with HA, AD DNS and OpenVPN peer-to-peer.

Branch Office is not a sitting duck when Main Office is not available. Normal DNS function maintained. Branch Office AD DNSs reach-ability is kept when HA is failed over.

Kudos to all!

Brgs,

No. Each node in an HA cluster needs to have the same set of WANs, you can't fail over for a gateway event.

@rico Thank you very much

0_1552590318279_dump.pcap

Set persistent CARP maintenance mode on the primary.

Status > CARP.

If you ALWAYS want the primary to boot into maintenance mode there is no supported way to do this, but you can install the shellcmd package and sort of force it.

You could install the Shell Command package (Will be in Services > Shellcmd after installation) and try to run this as a shellcmd.

/usr/local/sbin/pfSsh.php playback enablecarpmaint

Note that this will not discriminate as to the reason for the restart. Every time the system boots, it will set CARP Maintenance Mode.

You can fail back using the Leave Persistent CARP Maintenance Mode button in Status > CARP.

This is not really supported but might be a reasonable workaround for the issue you are describing.

Please let us know if this has the desired effect. I tested on 2.4.4-p2.

0_1552088536717_966800f6-15ee-44ad-81fc-726d447af955-image.png

Nice!
The ee editor is built in but if familiar with nano no reason not to install it. Also there's vi.....

Steve

Why would you not just resolve abc.def.com to 192.168.1.50 in the first place for devices behind pfsense...

I did the packet capture like you suggested, and I saw DNS requests coming over the VPN tunnel but nothing that was destined for the Internet. That got me thinking, so I checked my default route while connected to the VPN. Sure enough, the default route was to the local network gateway (instead of the VPN connection). I dug through my VPN settings a little and found that the "Use default gateway on remote network" wasn't checked. Checked that box, reconnected, and now it works!

@Derelict thank you for your help! ^_^ I was banging my head against a wall trying to figure this out lol

Documenting my solution:

Go to the interface settings for the VPN interface Go to the Networking tab and open IPv4 properties Open the Advanced window and check the "Use default gateway on remote network"

Hi Derelict.

Was able to get this setup. Worked a treat, easy as! Thanks for your help

Cheers
Mitch.

Well it is going to need at least a sync cable to sync over.

You might also want to disable XMLRPC sync on the restored primary until you are ready to do that too. Or ifnore that error.

If it is supposed to be syncing and cannot, you'll have to work out why there is no connectivity between the two.