Bug #4661
closed
OpenVPN client can't assign to GWGroup specifying VIPs
Added by z z over 9 years ago.
Updated about 9 years ago.
Description
- Failover pfSense with CARP —> OpenVPN client autostart OK.
- Failover multi-WAN —> OpenVPN client autostart OK.
- Failover pfSense with CARP + multi-WAN —> OpenVPN client can't assign to interface GateWay_Group.
http://rghost.ru/6Rc5hbZVJ.view
![](http://rghost.ru/6Rc5hbZVJ/thumb.png)
I made a virtual machine for the test (84,4 МБ).
Start VirtualBox. File -> Import -> pfSense.ova.
Start VM pfsense.
After start go to 192.168.1.10
Login admin
Pass pfsense
Menu VPN -> OpenVPN -> Client.
The settings in the screenshot.
http://rghost.ru/6XNb9t8cf.view
![](http://rghost.ru/6XNb9t8cf/thumb.png)
Error:
An IPv4 protocol was selected, but the selected interface has no IPv4 address.
How fix this error?
As I remember, when creating or editing an OpenVPN instance, the interface or highest tier of the gateway group to which it is assigned must currently have an IP address. I believe this is also a problem if you have a DHCP WANx and it is currently waiting to get DHCP (or the cable is not even plugged in).
The validation code here could be smarter to try and work out if the interface selected has IPv4/6 DHCP enabled, or if the gateway group looks like it has IPv4/6 members and then check if it matches the selected UDP or TCP 4/6.
WAN1 and WAN2 — static IP. May want to try it in my virtual machine for test.
I have this same issue.
I want to create MultiWan CARP, but when I choice Interface (GW Group Wan1FailoverWan2) on OpenVPN Server i get error message: The following input errors were detected:
An IPv4 protocol was selected, but the selected interface has no IPv4 address.
Wan1 and Wan2 have statis IP.
I'm using pfSense 2.2.2
I can choice WAN CARP IP and WAN2 CARP IP with no errors.
How to fix it? I need it!
Yesterday I discovered the same problem. Any chance to fix it in nearest release?
Thanks in advance!
- Subject changed from Failover pfSense with CARP + multi-WAN —> OpenVPN client can't assign to GWGroup to OpenVPN client can't assign to GWGroup specifying VIPs
- Category set to OpenVPN
- Status changed from New to Feedback
- Target version set to 2.2.3
- Affected Version set to 2.2.x
- Affected Architecture added
- Affected Architecture deleted (
i386)
fixed by what I just pushed, leaving for feedback. Will be in June 2 and newer 2.2.3 snapshots, or can gitsync to RELENG_2_2 if you want to try sooner.
Hello Chris.
I tested this twice,and it's not working properly.
I used version 2.2.3-DEVELOPMENT (amd64) built on Tue Jun 02 13:30:21 CDT 2015 FreeBSD 10.1-RELEASE-p10
Now I can choice Wan1VIPFailoverWan2VIP on OpenVPN Server settins.
1) working fine:
disconnect Wan1 cable on Node2 and next on Node1. OpenVPN Server listening on Node1 Wan2VIP -OK .tunnel was re-establish.
2) not working:
a) reboot/turn off Node1 . Node2 was marked as Master (from Backup). But OpenVPN server don't start. - Unable to contact daemon - Service not running?
b) disconnect only Wan1 cable on Node1 .Node2 was marked as Master (from Backup). But OpenVPN server don't start. - Unable to contact daemon - Service not running?
connect again Wan1 cable to Node1. Node1 was marked as Master and OpenVPN server starts again.
- Assignee set to Chris Buechler
- Target version changed from 2.2.3 to 2.3
Hello,
even worse, if a OpenVPN client in 2.2.3 is set to a GWGroup specifying VIPs, first it is working. Meening MultiWan failover happens but Node failover not. And what is really a pain in the ***, when you reboot the first node, the OpenVPN client wont start... So as a lookout VPN Admin I had to drive 800 km and click on start OpenVPN client service :-( (Okay, that is not true, but I had to give away the password for first node the start the client by remote hands... which is worse... :-) )
However, these symptoms could be interrelated. Why are the OpenVPN clients are not started, when node failover happens? Why are the OpenVPN clients are not started after a reboot?
Kind regards and I love pfSense
- Status changed from Feedback to Confirmed
- Target version changed from 2.3 to 2.2.4
- Status changed from Confirmed to Resolved
- Target version changed from 2.2.4 to 2.2.3
The original issue here was fixed in 2.2.3.
The issue Grzegorz and Cullen noted is separate. Opened #4854 for that one. Should have a fix pushed for that in a bit.
Also available in: Atom
PDF