Project

General

Profile

Actions

Bug #2273

closed

OpenVPN won't listen on interface 'any' after adding CARP vip's

Added by Bill McGonigle over 9 years ago. Updated over 9 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
OpenVPN
Target version:
-
Start date:
03/09/2012
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.0.1
Affected Architecture:

Description

After adding CARP VIP's, with the openvpn 'interface' parameter set to 'any', openvpn won't listen for connections.

I was adding CARP to a 2.0.1 box on which the OpenVPN instances listen to 'any' for Multi-WAN failover capability, and the remote OpenVPN connections weren't working afterwards. The processes were running:

[2.0.1-RELEASE][admin@pfsense.example.com]/root(46): ps ax | grep openvpn                                                     
  385  ??  Ss     0:00.07 /usr/local/sbin/openvpn --config /var/etc/openvpn/server1.conf                                              
 6587  ??  Ss     0:00.05 /usr/local/sbin/openvpn --config /var/etc/openvpn/server3.conf                                              
29362  ??  Ss     0:01.37 /usr/local/sbin/openvpn --config /var/etc/openvpn/server2.conf                                              
24346   0  R+     0:00.00 grep openvpn                                                                                                e

But, here is one server (of three) listening, the interface is set to the CARP VIP (blinded domain/first two octets of Internet address -192.168 substituted):

[2.0.1-RELEASE][admin@pfsense.example.com]/root(49): netstat -n -p udp                                                        
Active Internet connections                                                                                                           
Proto Recv-Q Send-Q  Local Address          Foreign Address       (state)                                                             
udp4       0      0 192.168.104.108.18578   96.44.157.90.123                                                                           
udp4       0      0 192.168.104.108.22693   46.166.138.172.123                                                                         
udp4       0      0 10.10.10.202.123       *.*                                                                                        
udp4       0      0 192.168.104.105.1193    *.*                                                                                        
udp4       0      0 10.10.10.202.161       *.*                                                                                        
udp4       0      0 127.0.0.1.19000        *.*                                                                                        
udp4       0      0 127.0.0.1.6969         *.*                                                                                        

Here, I change another server to listen on the VIP rather than 'any' and it immediately starts listening properly (udp 1194):

[2.0.1-RELEASE][admin@pfsense.example.com]/root(50): netstat -n -p udp                                                        
Active Internet connections                                                                                                           
Proto Recv-Q Send-Q  Local Address          Foreign Address       (state)                                                             
udp4       0      0 75.150.104.108.28881   74.117.214.3.123                                                                           
udp4       0      0 192.168.104.108.37209   74.118.152.85.123                                                                          
udp4       0      0 192.168.104.108.38463   72.14.179.211.123                                                                          
udp4       0      0 10.10.10.202.123       *.*                                                                                        
udp4       0      0 192.168.104.105.1194    *.*                                                                                        
udp4       0      0 192.168.104.105.1193    *.*                                                                                        
udp4       0      0 10.10.10.202.161       *.*                                                                                        
udp4       0      0 127.0.0.1.19000        *.*                                                                                        
udp4       0      0 127.0.0.1.6969         *.*                                                                                        

The 'any' interface selection was working great before adding the CARP VIP's. I see the CARP 'vip' interfaces just fine in ifconfig.

I don't know much about the OpenVPN code, but I do see things like:

  struct ifreq ifs[20]; // Maximum number of interfaces to scan

I wonder if adding 16 CARP interfaces (each AF_INET I think?) could overrun a limit. In the OpenVPN debug I see:

Fri Mar  9 01:28:57 2012 us=427476 Listening for incoming TCP connection on [undef]                                                   
Fri Mar  9 01:28:57 2012 us=427566 TCPv4_SERVER link local (bound): [undef]                                                           
Fri Mar  9 01:28:57 2012 us=427653 TCPv4_SERVER link remote: [undef]                 

on a failed server. I don't have any experience building pfSense, and I wasn't even sure how to find the shipped OpenVPN source (not in github?), so this is just going from a source download on my own machine (i.e. the above line may not be what's shipping in pfSense).

Unfortunately, due to bug #814, using multiple servers isn't a workaround at the moment for CARP plus Multi-WAN.

Actions #1

Updated by Chris Buechler over 9 years ago

  • Status changed from New to Rejected

"any" works fine with CARP and in any other circumstances. netstat doesn't show what's listening, only active connections. Use sockstat for that. We use stock OpenVPN with one exception fixing passtos which is in the port in the tools repo on github. This isn't a problem in our code and I really doubt it's a problem at all. In some circumstances with multi-WAN you can't use any and that's probably where you're going wrong. Better to bind to LAN and use port forwards for multi-WAN.

Actions

Also available in: Atom PDF