Project

General

Profile

Bug #8493

Assigned OpenVPN interface does not send traffic via right route until reboot

Added by Constantine Kormashev over 1 year ago. Updated over 1 year ago.

Status:
Not a Bug
Priority:
Very Low
Assignee:
-
Category:
Routing
Target version:
-
Start date:
05/03/2018
Due date:
% Done:

0%

Estimated time:
Affected Version:
Affected Architecture:

Description

In case of using several OpenVPN instances, e.g. Client (has its own default route) and Server on pfsense, assigned OpenVPN server interface does not send traffic via right route until device reboot (in some cases until pf restart).
I can see states and input traffic (10.0.10.0/24) on appropriate interface (OPT1) but does not see one output interface (LAN 10.0.11.0/24). Instead that I observe this traffic on WAN (default route) interface.

OPT1    icmp    10.0.10.2:1 -> 10.0.11.1:1  0:0     2 / 2   120 B / 120 B

Before reboot
OPT1
IP 10.0.10.2 > 10.0.11.1: ICMP echo request, id 1, seq 157, length 40
IP 10.0.10.2 > 10.0.11.1: ICMP echo request, id 1, seq 158, length 40

WAN
IP 10.0.11.1 > 10.0.10.2: ICMP echo reply, id 1, seq 157, length 40
IP 10.0.11.1 > 10.0.10.2: ICMP echo reply, id 1, seq 158, length 40

After reboot:
OPT1 and LAN
IP 10.0.10.2 > 10.0.11.1: ICMP echo request, id 1, seq 137, length 40
IP 10.0.11.1 > 10.0.10.2: ICMP echo reply, id 1, seq 137, length 40
IP 10.0.10.2 > 10.0.11.1: ICMP echo request, id 1, seq 138, length 40
IP 10.0.11.1 > 10.0.10.2: ICMP echo reply, id 1, seq 138, length 40

The issue affects Intel and ARM

after_reboot_status_output.tgz (112 KB) after_reboot_status_output.tgz after reboot status output Constantine Kormashev, 05/03/2018 03:08 AM
before_reboot_status_output.tgz (111 KB) before_reboot_status_output.tgz before reboot status output Constantine Kormashev, 05/03/2018 03:14 AM

History

#1 Updated by Jim Pingle over 1 year ago

  • Status changed from New to Not a Bug
  • Affected Version deleted (2.4.3)

After assignment, you must restart the VPN manually so OpenVPN can reapply the interface setttings which are stripped away by the assignment process. In the 'before' output, the OpenVPN server interface has no IP address and also no entries in the routing table for 10.0.10.x. This is consistent with the VPN not being properly restarted after assignment, which must be done manually.

#2 Updated by Constantine Kormashev over 1 year ago

Did not know about OpenVPN restart. Perhaps we need some hook for autorestart or warning there, because this is not obvious behavior.

#3 Updated by Jim Pingle over 1 year ago

It's noted in book section on assignment, and mentioned elsewhere as well.

#4 Updated by Constantine Kormashev over 1 year ago

Got it, no more questoins

Also available in: Atom PDF