Secure network does not conform to standard VPN IP structure (*.*.(11-255).0)

SUMMARY

Current secure network is set to 172.22.3.0 however following suspend and trying to reactivate we are getting an alert stating "Secure network does not conform to standard VPN IP structure (*.*.(11-255).0)"

ISSUE

Current secure network is set to 172.22.3.0 however following suspend and trying to reactivate we are getting an alert stating "Secure network does not conform to standard VPN IP structure (*.*.(11-255).0)"

RESOLUTION

On New Target Setup:

If this error is appearing make sure the IP range being inserted confirms to the alerts range (*.*(11-255).0) and does not conflict with existing local network subnets.
i.e. 172.22.13.0, 10.10.55.0, 192.168.254.0 etc.
User-added image

The third octet can be listed between 11 through 255, the first two octets can be set as needed.
The concern is to avoid conflict with Unitrends Cloud which sets in the (*.*(3-10).0) range.


On Existing Replication:

****FOR ERROR APPEARING ON EXISTING Source/Target REPLICATION SETUP ONLY****

The above UI screenshot will not allow correction once already setup. To correct setups on an existing target, go into /etc/openvpn/inbound.conf and edit the line stating the IP range from 172.22.3.0 to 172.22.11.0 

Target:
vi /etc/openvpn/inbound.conf

Find the section 
# Configure server mode and supply a VPN subnet
# for OpenVPN to draw client addresses from.
# The server will take 10.8.0.1 for itself,
# the rest will be made available to clients.
# Each client will be able to reach the server
# on 10.8.0.1. Comment this line out if you are
# ethernet bridging. See the man page for more info.
#server 172.17.3.0 255.255.255.0
server 172.22.3.0 255.255.255.0

Change the 172.22.3.0 to 172.22.11.0 (or any range where the third octet is within 11-255) and then save
# Configure server mode and supply a VPN subnet
# for OpenVPN to draw client addresses from.
# The server will take 10.8.0.1 for itself,
# the rest will be made available to clients.
# Each client will be able to reach the server
# on 10.8.0.1. Comment this line out if you are
# ethernet bridging. See the man page for more info.
#server 172.17.3.0 255.255.255.0
server 172.22.11.0 255.255.255.0
On the source and target update or remove the /etc/hosts entries for the old vpn setup to match the current vpn setup, leaving the nonVPN address listing of the target on the source as is. 

Target:

Remove or update any entries for the source's connected to the target from the target's hostfile
[[email protected] ~]# cat /etc/hosts
127.0.0.1               localhost.localdomain           localhost
10.10.1.74       Unitrends-DR 
172.22.3.6        UB-01
172.22.3.10       UB-02
[[email protected] ~]#
[[email protected] ~]# cat /etc/hosts
127.0.0.1               localhost.localdomain           localhost
10.0.174.74       Unitrends-DR 
172.22.11.6        UB-01
172.22.11.10       UB-02
[[email protected] ~]#
Restart openvpn following appropriate commands based on CentOS version on the target and confirm on the target that the new IP range is showing for the appropriate tun adapter
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:172.22.11.1  P-t-P:172.22.11.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:1270039280 errors:0 dropped:0 overruns:0 frame:0
          TX packets:684309158 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1590891640922 (1.4 TiB)  TX bytes:38315944969 (35.6 GiB)

Source:

Remove or update any entries for the target connected to the source from the source's hostfile
[[email protected] ~]# cat /etc/hosts
127.0.0.1               localhost.localdomain           localhost vCenter-RRC
10.10.1.72       UB-01
172.22.3.1       Unitrends-DR
10.10.1.73       Unitrends-DR-nonVPN
[[email protected] ~]#
 
[[email protected] ~]# cat /etc/hosts
127.0.0.1               localhost.localdomain           localhost vCenter-RRC
10.10.1.72       UB-01
172.22.11.1       Unitrends-DR
10.10.1.73       Unitrends-DR-nonVPN
[[email protected] ~]#

Restart openvpn following appropriate commands based on CentOS version on the source and confirm on the source that the new IP range is showing for the appropriate tun adapter. 
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:172.22.11.6  P-t-P:172.17.3.5  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:666094148 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1287881680 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:36227253812 (33.7 GiB)  TX bytes:1617639677811 (1.4 TiB)


 

CAUSE

Starting with release 10.4.0-1 in December 2019 we implemented fan-out replication that allows support for multiple replication targets per a single source. 

To avoid conflict with Cloud openvpn settings for customer now adding in customer owned targets we implemented a condition for openvpn setup to only allow the (*.*.(11-255).0) range for the customer owned target's openvpn settings. 

For new customers this alerts on setup of the target itself and in most cases is simple to assign a new IP before completing the setup process, however for existing customers we may see cases where previously setup openvpn tunnels are now triggering this alert following exiting suspension activity. As this function is locked for editing from the UI once setup we will need to edit the target's inbond.conf directly via ssh. 

 

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Contact us