Project

General

Profile

Bug #9225

Gateway group routing not updated on OpenVPN client reconnect

Added by Alexey Ab 5 months ago. Updated 8 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Routing
Target version:
Start date:
12/26/2018
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.4.4_1
Affected Architecture:
amd64

Description

Setup: PFSense 2.3.5 p1, or PFSense 2.4.4-p1

WAN1 - (PPPOE)
WAN2 - VPNV4 - Openvpn client in TUN mode connected via WAN1

Gateway group: Test_Group (VPNV4 - Tier1, WAN1 - Tier2)

Everything works as expected until WAN1 disconnect.

If I disconnect WAN1, WAN2 goes offline too in a minute or two.
When i reconnect WAN1, gateway group is updated (/tmp/rules.debug) with following:

GWWAN1_PPPOE = " route-to ( pppoe0 11.22.33.44 ) "
GWVPN_VPNV4 = " "
GWTest_Group = " route-to { ( pppoe0 11.22.33.44 ) } "

Then in several second OpenVPN goes online, but /tmp/rulse.debug contains following:

GWWAN1_PPPOE = " route-to ( pppoe0 11.22.33.44 ) "
GWVPN_VPNV4 = " route-to ( ovpnc3 10.8.0.5 ) "
GWTest_Group = " route-to { ( pppoe0 11.22.33.44 ) } " //!!! wrong: should be ovpnc3 10.8.0.5 (Tier1)

This is the final state, no matter how long you will wait. All gateways in gateway group are green (online), but routing goes through Tier2 gateway.

If i udpate ANY (even non related to this gateway group) firewall rule, or restart OpenVPN service then routing becomes correct:

GWWAN1_PPPOE = " route-to ( pppoe0 11.22.33.44 ) "
GWVPN_VPNV4 = " route-to ( ovpnc3 10.8.0.5 ) "
GWTest_Group = " route-to ( ovpnc3 10.8.0.5 ) "

So it seems then something is not updated when openvpn reconnects automatically (without restarting it's service).

(posted to forum, but no response: https://forum.netgate.com/topic/136937/pfsense-2-3-5-p1-gateway-group-not-updated-on-openvpn-client-reconnect )

History

#1 Updated by Jim Pingle 2 months ago

  • Target version changed from 48 to 2.5.0

#2 Updated by Riccardo Di Sarcina 8 days ago

I too have this exact problem, on multiple installations...

The problem exists with two PPPoE connections too.
Haven't tried with two static public IPs.

Also available in: Atom PDF