Do you get an IP if you're bridging and fill in the server bridge dhcp start/end?

If you do, then check your actual DHCP sever logs to see if it's being rejected for some reason there.

Make sure you read/understand the note under the bridge interface selector.

I thought I tried and read everything ::)

Thank you!
I didn't create the bridge interface necessary for the connection… Now I'm afraid to open a new topic for another bridging thing I keep failing at. I'll just keep messing with that one :P

For other people running into this; Create the bridge!
If you are running into the error:

OpenVPN Route: OpenVPN needs a gateway parameter for a --route option and no default was specified
OpenVPN Route: Failed to parse/resolve route for host network: ***

Define the DHCP start and end options.

//Edit:
Is it normal that interfaces with IP set to "None" have their own undeletable gateway and spawn syslog messages?

Feb 27 21:09:50 	php: : rc.newwanip: Failed to update opt10 IP, restarting...
Feb 27 21:09:50 	php: : rc.newwanip: on (IP address: ) (interface: opt10) (real interface: ovpns1).
Feb 27 21:09:50 	php: : rc.newwanip: Informational is starting ovpns1.

//Edit2:
Also, when applying these settings, a random CARP VIP goes down:

Feb 27 21:26:41 	kernel: opt2_vip1: link state changed to DOWN
Feb 27 21:26:41 	kernel: opt2_vip1: INIT -> BACKUP
Feb 27 21:26:41 	kernel: opt2_vip1: link state changed to DOWN

The first time I configured the OpenVPN bridging, I thought it could have been because I accidentally had the bridged interface in OpenVPN Settings configured to the interface opt2 for a minute. The second time though, I had left the OpenVPN settings bridged to the correct network and was extra cautious with creating the bridges but the same VIP still went down. There is no special reason for that interfaces VIP to be affected, I have other interfaces configured exactly the same. The only thing I can think of is that this is VIP1.
The solution was to 'edit' the settings for opt2, change nothing and apply settings.

The error seems to come from syncing the configuration to the other firewall:

Feb 27 21:26:41 	kernel: opt2_vip1: link state changed to DOWN
Feb 27 21:26:41 	kernel: opt2_vip1: INIT -> BACKUP
Feb 27 21:26:41 	kernel: opt2_vip1: link state changed to DOWN
Feb 27 21:26:41 	php: : Beginning XMLRPC sync to https://172.20.1.2:9180.
Feb 27 21:26:38 	check_reload_status: Syncing firewall
Feb 27 21:19:20 	php: : Filter sync successfully completed with https://172.20.1.2:9180.
Feb 27 21:19:12 	php: : XMLRPC sync successfully completed with https://172.20.1.2:9180.

Firewall 2 on 172.20.1.2 did not have the interface configuration yet at that time. When fixing the issue by 'editing' the opt2 interface, the correct configuration was already applied to the second firewall.

Funny thing is that FW1 shows the CARP IP to be down and generates a notification of a failing sync but FW2 doesn't even have a log entry of it.

If you do, then check your actual DHCP sever logs to see if it's being rejected for some reason there.

Make sure you read/understand the note under the bridge interface selector.