OpenVPN Remote Access Tap Bridge

Joolee

I've configured the OpenVPN server as folows:
Server Mode: Remote Access ( SSL/TLS )
Protocol: URP
Device Mode: tap
Interface: (CARP Virtual IP)
Local Port: 1194
IPv4/6 Tunnel Network: <empty>Bridge DHCP: Enabled
Bridge Interface: <interface with="" dhcp="" enabled="">Server Bridge DHCP Start & End: <empty>Redirect Gateway: Disabled
IPv4 Local Networks: 172.16.0.0/16,172.17.0.0/16,172.20.0.0/16,172.21.0.0/16,172.22.0.0/16
IPv6 Local Networks: <empty>Concurrent connections: <empty>Compression: Enabled (doesn't matter)
Type-of-Service: Enabled (doesn't matter)
Inter-client communication: Enabled (doesn't matter)
Client Settings: All disabled

The client can connect but doesn't get an IP. Adding the routes throws errors but that is probably due to not having an IP.
Setting the IP manually on the client doesn't work either. Received packages: 0
All interfaces got an Allow IPv4* rule with logging enabled. No packages are logged (except for WAN ofcourse)

Disabling the bridge mode for OpenVPN, configuring a tunnel network and setting "Provide a virtual adapter IP address to clients (see Tunnel Network)" Enabled works just fine. The client gets an IP, the routes get added and I can connect to hosts on the other side.</empty></empty></empty></interface></empty>

jimp

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.

Joolee

@jimp:

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.