Two-Spoke Setup (Hub, Hub Link, PE, CE Link PE) Troubleshooting
Two-Spoke Network Setup provides troubleshooting steps for connectivity and configuration issues. These include starting from the CE terminal, configuration checks, network connectivity tests, interface status checks, route inspection, firewall rule analysis, and examining log files. By following these steps, you can identify and resolve network communication issues.
Troubleshooting Steps
- Cloud
- UCI
- Run-Time
- Testing
- Log
Cloud Configuration Verification
Access the CE Terminal
Before you start troubleshooting, you must have the necessary permissions to run the commands. To do this, run the following command.
sudo su -
Checking OpenVPN Configuration
Run this command to view the OpenVPN configuration in the last applied settings:
cat /tmp/last_config_response.json | jq .interfacesConfig.openVpn
The given one is just an example output; when this command is run, it will show something like this.
Example Response
{
"vtun38_2": {
"trafficPolicy": "2mbps",
"trafficPolicyIn": true,
"trafficPolicyOut": true,
"caCertFile": null,
"certFile": null,
"keyFile": null,
"crlFiles": [],
"dhFile": null,
"pushRoutes": null,
"subnet": null,
"replaceDefaultRoutes": false,
"maxConnections": null,
"useLzoCompression": false,
"nameServer": null,
"cipher": "AES-256-CBC",
"authentication": null,
"interfaceName": "vtun38_2",
"bridgeGroup": "br38",
"tunnelType": "none",
"localPort": 50024,
"remotePort": 50024,
"localHost": null,
"remoteHost": "117.186.234.99",
"remoteHosts": [
"117.186.234.99"
],
"openVpnOption": null,
"persistentTunnel": true,
"vpnSharedSecret": "IwojIDIwNDggYml0IE9wZW5WUE4gc3RhdGljIGtleQojCi0tLS0tQkVHSU4gT3BlblZQTiBTdGF0aWMga2V5IFYxLS0tLS0KY2MzZTYzZjJmMjNiNDQ0YmUyYTk5YTBhYjgwZDQxMjkKM2RjMWZmMDM2YjdhNTZjMDcyOGFlMzBkYTRiMWJiZmEKYjRiZmJmZmVkNWFjNjJjMTg5NWQzYjIyNGE5NjkyYmYKNjljZGM0N2Y0YmM1MmU5ZmY3NzI3NjZkNzI4ZTBlMGYKOGRhNWVjNDgxOWRkMTJkZWNjNDQxZjU2NmZmMmY0MDEKZGMzNDAzOTliNDZkNWI1NzE5MTlkOThhNDJmNTdjZmIKMzFkNDk4YTY3ZjQzYzZkODA3MzY5Mjk3NGU5NTNmNzgKNWY2MWFmOThhOTUzZGJjYjg0ZjZmNzJiZjdhYjNiMjcKNWIwZDY2MGNkYzdiMDAwZjFjYTg5NmVlMTcwYTM5N2UKMzBiMWU3ZjBlOWM2MWE0ZWVmYzM5ZGRjNmE2YWI5MDcKYTM3MzViNzNlNjgxMmQxNmQwZTVjMGZjMzVkMmRkYWIKY2JmM2NlMjI0YjcyOTdmZTczY2EwMjViOTk3ZjM1YmMKYTc4MWQ1ODMwMjFiMDk3N2ZkOTg4MzQ2NWVhNmUxNjgKMzcxODZiMWJjN2NlNDM1ZTViYjRmMGVlMGVkNzVkM2MKMjhkZTU1ODM0OGI1Y2Q5NzM0Y2QwNjljOTQ5M2JjMTMKOTU4NzU1NzcyMTQwZGZmZmMxYjhmYzkzOTIyZGZmMWIKLS0tLS1FTkQgT3BlblZQTiBTdGF0aWMga2V5IFYxLS0tLS0K",
"splitTunnel": false,
"socksProxy": false,
"socksProxyType": null,
"socksProxyPrivateKey": null,
"socksProxyPublicKey": null,
"description": "6426ea7e83066500241c5f3a@hiclouds.io ( SHA - sha-bate1-pe1 ) ( vtun38_2 ) ",
"wanInterfaces": null,
"mode": "site-to-site",
"protocol": "udp",
"ceDeviceId": null,
"ceDeviceLabel": null,
"customerEmail": null,
"status": null,
"peDeviceIds": [
"67c579ae37591440308f3d34"
],
"hubCEDeviceIds": [],
"ceSpokeId": null,
"remoteDeviceLabel": null,
"ethInterface": null
},
"vtun38": {
"trafficPolicy": null,
"trafficPolicyIn": false,
"trafficPolicyOut": false,
"caCertFile": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUN4VENDQWEyZ0F3SUJBZ0lHQVljNEEvNmNNQTBHQ1NxR1NJYjNEUUVCQ3dVQU1Ca3hGekFWQmdOVkJBTU1EazFoYm5WaGJDMVVaWE4wYVc1bk1CNFhEVEl6TURNek1URTBNVE14T0ZvWERUTXpNRE15T0RFME1UTXhPRm93R1RFWE1CVUdBMVVFQXd3T1RXRnVkV0ZzTFZSbGMzUnBibWN3Z2dFaU1BMEdDU3FHU0liM0RRRUJBUVVBQTRJQkR3QXdnZ0VLQW9JQkFRQ0VOR1JkN0dDRVo1anB6bTRTVmNDZEZibFdMb2VQc1g0cnM2dnhhdFFIZDhtUmtoWDRkUU9NR0pkelJ5bWsyNXhqbEhzRHNGZkpSSWJzZVY1bG1WajZISVEzaXhyWUVWaTF2aTNxemVuR1FwcncrKzFGcmx3M096cXlySUxVV0pabGNDL3U0cVNVcUJyMXBkWXF2QkVPa2UxTXh2RkxkM1FoYytzK2pEOXYyOXhzbUNBdzFtRDlPTVNVdEh5RSt0UzBqM1lTRExxcWNpQlFHYzlTNXh1akRoRkFac3dvNTVhZHc3OWRLbWRCcnNvQ0YzQUpub0JJenQvaEhrUE1mTG9XcXUwc3NXdjNkLzhXOUo2c2JPWkRIbDI3Ums0eVBDZTF0SStnZUN4ajhtL01URmhjQWFDeGNzUUJLclBXR3BHKytjdTRxZnRHMm82Q2VPVnl0Qm1CQWdNQkFBR2pFekFSTUE4R0ExVWRFd0VCL3dRRk1BTUJBZjh3RFFZSktvWklodmNOQVFFTEJRQURnZ0VCQURBMlo4WmZWSVJiYlVQZCtIOW5YNHVtSVFYeDR0RHVKaEhKZzVIVWhDRzZJZitzbjRLbTdQV0pZVVhTTSsxRHk1S09vV1VNN0lrVjRTeVFyVWw5dmtjR3RKMnRPT3oxSERJUjc4bDRidk5tWVdFaEdaeFBKR3RBVllaOGtSV2trVHNQUDltQlRndWFMTkt6ZDcySTFLKzdiOUpzUGliclcyOCt3bzRlNWhPdUVRR0xtd3NoMm1jWGVSRWs3STlKOTVwUFBQdytDVXN6aGVyeDkvbWVYcFpRb25nWGZaaDFzTWRuRjhHWWVkaEZ6M0IzUENHTllZcWFrb0lVbnZSMzRheTZpSnJkRHFGa0hyOEtkQ2tJWVh0U1hYWWVSbFBpWWsxQ3VIQWg0RFFKMXhWQ3FUVmFJaDByRG5zZjBrZnE4RktuSWo1S0ZRL3lYQmhlUWQ0YmZnVT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQ==",
"certFile": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUN1akNDQWFLZ0F3SUJBZ0lHQVplQjZLUHVNQTBHQ1NxR1NJYjNEUUVCQ3dVQU1Ca3hGekFWQmdOVkJBTU1EazFoYm5WaGJDMVVaWE4wYVc1bk1CNFhEVEkxTURZeE9EQTNNVGsxTmxvWERUTTFNRFl4TmpBM01UazFObG93SXpFaE1COEdBMVVFQXd3WU5qZzFNalk0T0RjMU1EY3hNR0V4T0RBeE1UUTBaREJrTUlJQklqQU5CZ2txaGtpRzl3MEJBUUVGQUFPQ0FROEFNSUlCQ2dLQ0FRRUFwNlJWdEMyN0hwZ2lmakdrNVlSVDQ3VDJHWjBXZCtnZWZSV0NrcklkRDE5ZmhMNDlNeE1iL08zdG4xbXpMNWVPQW5WTTVJbnFNeVhudXg2QUNkYjBlYjFiSmlOTFFlaXlJMEVOSHhoSVJxQjBFSjQ4TlhaUktGYWxEWHFKdHR4R2VCcS9EVEN4OWVVcUxjUS8zM3ZBcFNxamYyV25tcnY1UHdsTWEvT2NTU3BhNVZ3K01LanJwTUtiajMrN1EyejFTdU1Bazl2Nk00NDdPeElrL05zYVg1WWJwb0Vmb296aXZxb0FpaVBWa0ZWd1BPOCszQ1dkTXZBTXlkaGFlaHR2cUhvZlJIUFA2ODJpeEVIVHhyMDN5L0luT1hvcWVSS2U5VWpNNVNGUERmU3ZjdFQrQXI1UVhuaUoxa1cwcnZGY3ZCcW9Xb3VXOWlpbVg1NWZKdGtjcVFJREFRQUJNQTBHQ1NxR1NJYjNEUUVCQ3dVQUE0SUJBUUNDT01XWWVQc0RRQVNDVzcxTjU4eVprQ1RQS3g5RE5oNmZ5bi8vRGk1ODlMNHJOL0l1Y0JYYVY4a2txR3pHOEtBL1hCUXc4MXR5Q25GOWhyMjdvWkZYRGtERXlZdnFxUVRnMHozUnFIM3dyblJJd290YjBLYVBFK3AyTkV3NzJTbkNHSE13dk15TEZBekpUV3NXdU5reUUzWldDckFESGkwNFRkdnFvbE9KbGI4Y1pBTFJ3eHlKYmsvK0dDVVluWmdqOU5oV0hHYmVYeFhjK1NtWmZUUjUwWFZ3a0lIK1o1T0hPMWxHMkpCRjJqZ0ZaS2dpMHdod1N0NGFnRWhsVEs3T3RPTDhlWVlkQjVjS1hCYjIxZGRIMWZyZEUxS2J5cm4wWkZJQkxpUzNBVUw4Z2JCKzFRM0V4NFB6amdobURmbUhSQnBubDREUnYwQUtTM2FJaHpsOAotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0t",
"keyFile": "LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCk1JSUV2UUlCQURBTkJna3Foa2lHOXcwQkFRRUZBQVNDQktjd2dnU2pBZ0VBQW9JQkFRQ25wRlcwTGJzZW1DSitNYVRsaEZQanRQWVpuUlozNkI1OUZZS1NzaDBQWDErRXZqMHpFeHY4N2UyZldiTXZsNDRDZFV6a2llb3pKZWU3SG9BSjF2UjV2VnNtSTB0QjZMSWpRUTBmR0VoR29IUVFuancxZGxFb1ZxVU5lb20yM0VaNEdyOE5NTEgxNVNvdHhEL2ZlOENsS3FOL1phZWF1L2svQ1V4cjg1eEpLbHJsWEQ0d3FPdWt3cHVQZjd0RGJQVks0d0NUMi9vempqczdFaVQ4MnhwZmxodW1nUitpak9LK3FnQ0tJOVdRVlhBODd6N2NKWjB5OEF6SjJGcDZHMitvZWg5RWM4L3J6YUxFUWRQR3ZUZkw4aWM1ZWlwNUVwNzFTTXpsSVU4TjlLOXkxUDRDdmxCZWVJbldSYlN1OFZ5OEdxaGFpNWIyS0taZm5sOG0yUnlwQWdNQkFBRUNnZ0VBSE1LMVQyV2ZHaWNZbDlUVmlPalVhWmIwdDcwN0N4UkFFczZiYWFaMEZOeVVheFltTXJwL0RUd1dqY1dhVjdwbEN5ZnJxck84Z2N6cGZqRkQzeXhKSWcrcDhSZVNCRHN6UUpnYTg3QTdTaDZoK3UzaXYzdE9maUNyVFc0dDdUaktRRFc2ZkQxVDhxOC90cjFhQmZIWndaeFlrM1V4dFhxMVRxcStPVEVBcVk1N0ZEL0tlb1BhTm5nR1lyTzFSb1NTc1Jrem5LeGNnTnJSTlhsTGpGcnVpaG1FUldCdGhsNmR3bHA4d1g2VDBGNnRsZnVSVHRtU21SZkxYSGgxQTBYZ3lqL3VTTExOakZmaGtaajlSMVlDWGNRZ1VtYlkwMHBOOHNUeFgwQUVsTUdYQWxaS2tlNDNaYmxNSDg1RUdYaEcwREVlbERKcWxQZktSaVBkMW8xd0dRS0JnUURMUTU0RjVybElGQmdNNjJsdXdOOVE3bzdIMEFubEtPWUZqNkNyeWZ0dWovTVF5V0hiMmtwNm56QjFoZ3ZzSVdXUnJUSGoyOE5uZEdQTnMrRDFWbGErdU55Q21SQlZnU0RJOG04cG4yWDREQk1LdnZVTitlWEVQSGk2YktZeHhIRDlrcEpHbzNFQ2hBR1RBa05oRWdvT0NOd1cyK2U2bGs2WGpFbWd5UzZPTlFLQmdRRFRJc1BRMS9Xem5CYzVZOFpWN2xydWJHSWoxK1JRMzNVZ2FKSkxSVlFGaXJiM3p3dnA0bmFGZVBZcVFzRzJ3RnVyT2N1eGNkMllRc0crR0ZPNzVRZ1lzNVM0Vkoxei9ocXRnRFVIUDEzYjFZay9tVVBvYnRqYTdOZDkxUVAxVEkvQmxvMHNEbzYreklhY0Y2NGhUTkZDeUE1NWd4U0FyLzA2NVZ4VGV1SXpKUUtCZ0JhNldORVFHMmVUMTV5YU5nL01RU3dyZ0l1WEY0UW9McEF3bnlhV1R5YnRzYUFPNUlKUXhrTXZ5WnRhZ2JyRmdUWG94OHRTcDJiSi9ON2pYaVFRbzJKd0NUZ1JKV0pxTGVCS08yUE1EdnJOWHRPMHhuSHBuMmR4MjQzODJCaDRmcW5iMmI5TVJ6YWd6QXhFRklTbUg3bXlBK29LYkw3UVQ3bGlWbGxFSlpDQkFvR0JBTTBDSGFha2UyT1o5WWI1RlhVTXl1aGsvdW9VMEJHaTJDVE94UFluYkEweGdyV2VLZEJBMzVwOE9ISVNmZXZJWFhvbDFWNEgxUVhxRkJ0VG5jSjlBZDZTU0o2dk1tK1ZWU3dRcCt6UW4zODhtVmJTcC9pQjRUaTU3Z2UxbFhGU2xPZUJHclNqc2dFYnNMelIxWGRxRW1ySXZCMUtwTmJMaTVQcmJ6bHp3VDJ0QW9HQWFqNEgzTTVYRCtMRUlCamtGOGozei9iSTFMMHZwN2RGQXlPUTFSK1A4aitDNHZPOEZBdlp1b2d5TXVraUNGbStndjBteWhQT1A1ckFqRmp3SUlvbDNNMmNpelpncFN4NkJBNnd5a3JpYWdoWERYTnFrTWtONXJFNW9VYVErUS9HbllDNG9ISGVYeW1qYmRJWGtaV3RUaHF4NmdOczNVMzY5bDk3OUptL1krTT0KLS0tLS1FTkQgUFJJVkFURSBLRVktLS0tLQ==",
"crlFiles": [],
"dhFile": null,
"pushRoutes": [],
"subnet": "172.29.2.0/24",
"replaceDefaultRoutes": true,
"maxConnections": 20,
"useLzoCompression": true,
"nameServer": "172.29.2.1",
"cipher": "default",
"authentication": {
"authenticationMethod": "PLATFORM",
"office365": null,
"ldap": null
},
"interfaceName": "vtun38",
"bridgeGroup": null,
"tunnelType": null,
"localPort": 11940,
"remotePort": null,
"localHost": "192.168.31.225",
"remoteHost": null,
"remoteHosts": [],
"openVpnOption": null,
"persistentTunnel": true,
"vpnSharedSecret": null,
"splitTunnel": false,
"socksProxy": false,
"socksProxyType": null,
"socksProxyPrivateKey": null,
"socksProxyPublicKey": null,
"description": "Vpn Server",
"wanInterfaces": null,
"mode": "server",
"protocol": "udp",
"ceDeviceId": null,
"ceDeviceLabel": null,
"customerEmail": null,
"status": null,
"peDeviceIds": [],
"hubCEDeviceIds": [],
"ceSpokeId": null,
"remoteDeviceLabel": null,
"ethInterface": "eth0"
}
}
Q:1 I ran the command but got “No such file or directory”. What does it mean?
If you see “No such file or directory” when running: cat /tmp/last_config_response.json | jq .interfacesConfig.openVpn. it means the configuration file does not exist in the /tmp directory. Common reasons include: The cloud configuration was never pushed to the CE device. The CE device has not synchronized with the cloud platform. The file was not generated due to a failed configuration update. In this case, verify that the hub and spokes were properly created in the cloud, then re‑push the configuration to the CE device and restart the VPN service.
Q:2 Why is the remoteHost field important?
The remoteHost field specifies the IP address or hostname of the remote VPN peer (e.g., the hub or spoke device). It is critical because: Without it, the VPN client does not know where to connect. It defines the endpoint for tunnel establishment. Incorrect or missing values will cause connection failures or unreachable peers. In multi‑spoke setups, each spoke must have the correct remoteHost pointing to the hub or PE device. In short, the remoteHost field is the destination address for the VPN tunnel, and misconfiguration here is one of the most common causes of connectivity issues.
UCI Configuration Verification
Verify Netwrok Configuration Details
Use the command uci show network | grep route to view the static routes configured on the CE device (such as a router). This command displays the UCI network configuration for a Route.
uci show network | grep route
The given one is just an example output; when this command is run, it will show something like this.
Example Response
network.746905bb4d2a41ec921b7405b9b2d19e=route
network.161c2013f1a44f5d8f0ff2086758bcb1=route
network.bffa3cfac3314a11b7465d00093a9e47=route
Check Firewall Rules:
show firewall rules
Check the firewall rules on both the hub and CE devices. Make sure there are no rules blocking traffic between the hub and CE, especially on the VPN tunnel. Allow traffic on the VPN interface if necessary.
Q:1 What does the output of the uci show network | grep route command represent?
The output of: uci show network | grep route. represents the static routes configured on the CE device. Each entry (e.g., network.ID =route) corresponds to a route definition stored in the UCI configuration. These routes define: Target network/subnet – The destination IP range the CE device should reach. Gateway – The next-hop IP address used to forward traffic. Interface – The network interface (e.g., br38) through which the traffic is routed. Priority/metric – Determines the preference if multiple routes exist. This command helps confirm that routing between the hub and CE devices is correctly defined.
Q:2 What should I check in firewall rules during VPN or connectivity troubleshooting?
When checking firewall rules, focus on: VPN tunnel interface rules – Ensure traffic on the VPN interface (e.g., tun or tap) is allowed. Inbound/outbound policies – Verify that packets from spoke LANs to the hub and vice versa are not blocked. Port allowances – Confirm that VPN ports (e.g., UDP 1194 for OpenVPN, IPsec ports 500/4500) are open. NAT rules – Check that NAT is not interfering with VPN traffic unless explicitly required. Drop/deny rules – Look for any rules that may unintentionally block inter-device communication. Proper firewall configuration ensures that VPN traffic flows freely between hub and spokes.
Q:3 Do I need to check firewall rules on both Hub and Spoke?
Yes, firewall rules must be checked on both the Hub and CE devices because: Hub firewall* – Controls traffic entering and leaving the central hub, including spoke-to-spoke communication. Spoke firewall – Controls traffic between the spoke LAN and the VPN tunnel, ensuring local devices can reach the hub. Misconfiguration on either side can block communication, even if the VPN tunnel itself is established. Checking both ensures end-to-end connectivity across the two-spoke setup.
Run time Configuration Verification
Verify VPN Tunnel Status (PE Connectivity)
The PE device should be successfully connected via CE. There should be three tunnels visible: two for the hub and one for the PE. Both should be in the active state (usually shown in green).
- What to look for:
- A tunnel connected to the hub.
- A tunnel connected to the PE.
Verify CE to PE Connectivity
Once the CE connection is established on the PE, check if the CE device is communicating with the PE properly.
-
Please visit the documentation for the CE-to-PE connection. This typically involves verifying the connections between the CE and PE.
-
After connecting CEs to PEs, they form "peers" that can connect and communicate with each other, and CEs must remain connected.
Check OpenVPN Service
Check if the OpenVPN service is running on the CE device. Use the following command for its service status.
- To check if the OpenVPN service is running, execute:
/etc/init.d/openvpn status
- If the OpenVPN service is not running, start it by executing:
/etc/init.d/openvpn start
- If you need to stop the OpenVPN service, use the following command:
/etc/init.d/openvpn stop
Q:1 How to verify CE-to-PE connectivity?
To verify CE-to-PE connectivity: Check the PE device tunnel status – Ensure the CE device is listed as connected and the tunnel is active (green). Run ping tests – From the CE device, ping the PE device IP to confirm reachability. Inspect peer relationships – Verify that the CE and PE are listed as peers in the VPN configuration. Review logs – Use logread | grep ipsec or logread | grep openvpn to confirm successful handshake and data flow. This ensures the CE device is properly communicating with the PE and participating in the VPN peer group.
Q:2 Tunnel is not in active state? What to do?
Start with PE status and firmware, then verify config, services, routes, firewall, and logs.
Q:3 How to check OpenVPN service status?
To check the OpenVPN service status on the CE device, run: /etc/init.d/openvpn status. If the service is running, it will display as active. If not running, start it with: /etc/init.d/openvpn start. To stop the service, use: /etc/init.d/openvpn stop. This confirms whether the OpenVPN process is operational and ensures the VPN tunnel can be established.
Testing Verification
Verify Hub to CE Connectivity (Routing Check)
The CE-PE connectivity has been established. Proceed to verify end-to-end routing to ensure hub-to-CE communication is functional.
Ping the CE's LAN IP from the hub:
ping CE_LAN_IP
Replace CE_LAN_IP with the local area network (LAN) IP address of the Customer Edge (CE) device. If the ping fails, it indicates a routing issue.
Check Routing Logs:
logread | grep route
The given one is just an example output; when this command is run, it will show something like this.
Example Response
Jun 24 06:47:04 manual-testing dnsmasq-dhcp[1]: IPv6 router advertisement enabled
Jun 24 06:47:05 manual-testing dnsmasq-dhcp[1]: router advertisement on eth3
Jun 24 06:47:05 manual-testing dnsmasq-dhcp[1]: IPv6 router advertisement enabled
Jun 24 06:47:08 manual-testing dnsmasq-dhcp[1]: router advertisement on eth3
Jun 24 06:47:08 manual-testing dnsmasq-dhcp[1]: IPv6 router advertisement enabled
This command searches the system log for information related to "routes". It checks for changes made to the routing table, new routes added or removed, and any errors or warnings.
Q:1 Which command can be used to check routing logs?
To check routing logs on the CE device, use: logread | grep route. This command filters the system log for entries related to routing events. It shows when routes are added, removed, or modified. It also highlights any errors or warnings related to routing, which helps identify misconfigurations or connectivity issues.
Log Verification
Checking logs can help you diagnose specific issues, such as failed authentication attempts or service errors.
Check openvpn Logs:
logread | grep openvpn
The given one is just an example output; when this command is run, it will show something like this.
Example Response
Jun 24 06:47:03 manual-testing openvpn(vtun38_2)[4790]: DEPRECATED OPTION: The option --secret is deprecated.
Jun 24 06:47:03 manual-testing openvpn(vtun38_2)[4790]: DEPRECATION: No tls-client or tls-server option in configuration detected. OpenVPN 2.7 will remove the functionality to run a VPN without TLS. See the examples section in the manual page for examples of a similar quick setup with peer-fingerprint.
Jun 24 06:47:03 manual-testing openvpn(vtun38_2)[4790]: OpenVPN 2.6.13 x86_64-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Jun 24 06:47:03 manual-testing openvpn(vtun38_2)[4790]: library versions: OpenSSL 3.0.16 11 Feb 2025, LZO 2.10
Jun 24 06:47:03 manual-testing openvpn(vtun38_2)[4790]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jun 24 06:47:03 manual-testing openvpn(vtun38_2)[4790]: TUN/TAP device vtun38_2 opened
Jun 24 06:47:03 manual-testing openvpn(vtun38_2)[4790]: /usr/libexec/openvpn-hotplug up vtun38_2 vtun38_2 1500 0 init
Jun 24 06:47:05 manual-testing openvpn(vtun38_2)[4790]: TCP/UDP: Preserving recently used remote address: [AF_INET]117.186.234.99:50024
Jun 24 06:47:05 manual-testing openvpn(vtun38_2)[4790]: Socket Buffers: R=[212992->425984] S=[212992->425984]
Jun 24 06:47:05 manual-testing openvpn(vtun38_2)[4790]: UDPv4 link local (bound): [AF_INET][undef]:50024
Jun 24 06:47:05 manual-testing openvpn(vtun38_2)[4790]: UDPv4 link remote: [AF_INET]117.186.234.99:50024
Jun 24 06:47:05 manual-testing openvpn(vtun38_2)[4790]: write UDPv4 []: Network unreachable (fd=6,code=101)
Jun 24 06:47:05 manual-testing openvpn(vtun38_2)[4790]: write UDPv4 []: Network unreachable (fd=6,code=101)
Jun 24 06:47:05 manual-testing openvpn(vtun38_2)[4790]: write UDPv4 []: Network unreachable (fd=6,code=101)
Jun 24 06:47:16 manual-testing openvpn(vtun38_2)[4790]: Peer Connection Initiated with [AF_INET]117.186.234.99:50024
Jun 24 06:47:18 manual-testing openvpn(vtun38_2)[4790]: Initialization Sequence Completed
Jun 24 06:47:18 manual-testing openvpn(vtun38_2)[4790]: Data Channel: cipher 'AES-256-CBC', auth 'SHA1'
Jun 24 06:47:18 manual-testing openvpn(vtun38_2)[4790]: Timers: ping 10, ping-restart 60
Jun 24 07:00:06 manual-testing openvpn(vtun38_2)[4790]: write UDPv4 []: Operation not permitted (fd=6,code=1)
Jun 24 07:08:45 manual-testing hiclouds_config.sh[7764]: execute post config command "/etc/init.d/openvpn restart vtun38"
Jun 24 07:08:47 manual-testing openvpn(vtun38)[9784]: WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
Jun 24 07:08:47 manual-testing openvpn(vtun38)[9784]: DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations.
Jun 24 07:08:47 manual-testing openvpn(vtun38)[9784]: OpenVPN 2.6.13 x86_64-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Jun 24 07:08:47 manual-testing openvpn(vtun38)[9784]: library versions: OpenSSL 3.0.16 11 Feb 2025, LZO 2.10
Jun 24 07:08:47 manual-testing openvpn(vtun38)[9784]: WARNING: --ping should normally be used with --ping-restart or --ping-exit
Jun 24 07:08:47 manual-testing openvpn(vtun38)[9784]: WARNING: --keepalive option is missing from server config
Jun 24 07:08:47 manual-testing openvpn(vtun38)[9784]: net_route_v4_best_gw query: dst 0.0.0.0
Jun 24 07:08:47 manual-testing openvpn(vtun38)[9784]: net_route_v4_best_gw result: via 0.0.0.0 dev
Jun 24 07:08:47 manual-testing openvpn(vtun38)[9784]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jun 24 07:08:47 manual-testing openvpn(vtun38)[9784]: Diffie-Hellman initialized with 1024 bit key
Jun 24 07:08:47 manual-testing openvpn(vtun38)[9784]: TUN/TAP device vtun38 opened
Jun 24 07:08:47 manual-testing openvpn(vtun38)[9784]: net_iface_mtu_set: mtu 1500 for vtun38
Jun 24 07:08:47 manual-testing openvpn(vtun38)[9784]: net_iface_up: set vtun38 up
Jun 24 07:08:47 manual-testing openvpn(vtun38)[9784]: net_addr_v4_add: 172.29.2.1/24 dev vtun38
Jun 24 07:08:47 manual-testing openvpn(vtun38)[9784]: /usr/libexec/openvpn-hotplug up vtun38 vtun38 1500 0 172.29.2.1 255.255.255.0 init
Jun 24 07:08:48 manual-testing openvpn(vtun38_2)[4790]: write UDPv4 []: Operation not permitted (fd=6,code=1)
Jun 24 07:08:49 manual-testing openvpn(vtun38)[9784]: Could not determine IPv4/IPv6 protocol. Using AF_INET
Jun 24 07:08:49 manual-testing openvpn(vtun38)[9784]: Socket Buffers: R=[212992->212992] S=[212992->212992]
Jun 24 07:08:49 manual-testing openvpn(vtun38)[9784]: UDPv4 link local (bound): [AF_INET]192.168.31.225:11940
Jun 24 07:08:49 manual-testing openvpn(vtun38)[9784]: UDPv4 link remote: [AF_UNSPEC]
Jun 24 07:08:49 manual-testing openvpn(vtun38)[9784]: MULTI: multi_init called, r=256 v=256
Jun 24 07:08:49 manual-testing openvpn(vtun38)[9784]: IFCONFIG POOL IPv4: base=172.29.2.2 size=253
Jun 24 07:08:49 manual-testing openvpn(vtun38)[9784]: Initialization Sequence Completed
Jun 24 07:15:33 manual-testing hiclouds_config.sh[16093]: execute post config command "/etc/init.d/openvpn stop vtun38_2"
Jun 24 07:15:33 manual-testing openvpn(vtun38_2)[4790]: event_wait : Interrupted system call (fd=-1,code=4)
Jun 24 07:15:33 manual-testing openvpn(vtun38_2)[4790]: /usr/libexec/openvpn-hotplug route-pre-down vtun38_2 vtun38_2 1500 0 init
Jun 24 07:15:33 manual-testing openvpn(vtun38_2)[4790]: Closing TUN/TAP interface
Jun 24 07:15:33 manual-testing openvpn(vtun38_2)[4790]: /usr/libexec/openvpn-hotplug down vtun38_2 vtun38_2 1500 0 init
Jun 24 07:15:33 manual-testing openvpn(vtun38_2)[4790]: SIGTERM[hard,] received, process exiting
This command searches for OpenVPN-related information in the system logs. It reveals any errors related to tunnel creation, authentication, certificate validation, or connection failures. These logs are useful for identifying why OpenVPN tunnels are not starting or are frequently disconnected.