Project

General

Profile

Bug #9004

Default gateway IPv4 set to a group fails after restart on 2.4.4

Added by Daniel Williams 10 months ago. Updated 2 months ago.

Status:
Resolved
Priority:
High
Category:
Routing
Target version:
Start date:
10/04/2018
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.4.4
Affected Architecture:
amd64

Description

We set the default gateway IPv4 to be a group, called WAN_Failover. That group consists of WAN1 Fiber at tier 1 and WAN2 Cable at Tier 2.

After a reboot of the PFSense hardware, the PFSense can see no default gateway by which traffic can be routed, no client have any internet access. We locally can get to the PFSense box and log in without issue. We went to the Diagnostic | Ping page; the PFSense can ping out by WAN1 or by WAN2, but if you set the source address to be Automatically selected (default), PFSense cannot perform a ping test, stating that no route is available. We then go back to System | Routing and change the Default Gateway IPv4 to the WAN1 (fiber circuit), go back to ping out, and can ping via automatic (as WAN is the default). Now the odd part starts, we change the Default Gateway IPv4 back to WAN_Failover and everything works fine - clients get to the internet, ping out automatic works fine - all is fine. After a firewall reboot, no outbound traffic will be passed until we change the Default Gateway IPv4 to WAN and apply - after this traffic is then passed without issue. We now can change the Default Gateway IPv4 back to the gateway group WAN_Failover and all will still work fine.

This is repeatable.

Gateway group.JPG (40.7 KB) Gateway group.JPG Daniel Williams, 10/04/2018 08:49 AM
Default routing changed to WAN1.JPG (79.5 KB) Default routing changed to WAN1.JPG Daniel Williams, 10/04/2018 08:49 AM

History

#1 Updated by Travis McMurry 9 months ago

I thought I was going crazy, because I have this same configuration 2 wans (1 cable, 1 4G/LTE) in a gateway group. This caused me to scratch my head a little. I selected the default gateway to be the gateway group and things were fine. I shut down, added an additional CPU core to pfSense to address a different issue (snort), started it back up and saw two things:

1) Your symptoms as reported, verbatim. Go to diagnostics -> routes, there is no default route set on IPv4.
2) However, I noticed IPv6 had a default route.

Only after manually setting wan1 as the default route in routing for IPv4 does the default get set. Changing WAN1 back to the gateway group, everything still works. However a subsequent gateway group failover will pull the default route again and not set it back to the active gateway - which may be a different problem altogether.

I found it strange when things weren't working, that pinging 8.8.8.8 from pfsense's console revealed "no route to host" WHILE pfSense (dpinger) was successfully pinging a different IP from wan1 and reporting no packet loss and nominal latency, yet no internet access. Swapping the DG manually- changing no other setting - made everything work.

If I'm making an incorrect assumption on the behavior of this new feature, I'd like to know what it should be. Documentation is not up to date with the current 4.4 release @ https://www.netgate.com/docs/pfsense/routing/gateway-settings.html.

#2 Updated by Daniele Palumbo 8 months ago

Daniel Williams wrote:

This is repeatable.

+1, i have had the same.

Also
https://www.netgate.com/blog/pfsense-software-version-2-4-4-release-highlights.html
"""
Gateway improvements

A default gateway can now be a part of a group. In previous pfSense versions default gateway switching didn’t have any particular order, and users didn’t have control over which gateways were picked upon outage. With version 2.4.4, users can specify in a group which gateway to use first, second, third, etc.

Also improved is gateway monitoring. Users can now set the gateway monitoring probe interval to a much higher value. This is very useful with low bandwidth connections such as mobile networks / 3G / 4G.
"""

Was something changed in the backend as well?

#3 Updated by Daniele Sorrenti 8 months ago

+1. This problem also affects my environment. Default route is not set after restart if default gw is a group gw, and also default route not update after a fail. I need to change manually the default gw to another, and go back to the group gw every time.

#4 Updated by Jim Pingle 8 months ago

See also: #9153

#5 Updated by Arthur Wiebe 8 months ago

We also experienced this issue today. Had to set the "Default gateway IPv4" setting to WANGW so that pfSense could get back online.

#6 Updated by Daniele Sorrenti 8 months ago

2.4.4p1 also affected.

#7 Updated by J Noebas 7 months ago

+1 had this on a system after a reboot but on a other system with multiple vlan interfaces i had to change the ip of the management for 192.168.1.254 to something else due to overlapping and after setting this the route was also gone.

#8 Updated by Peter Schovits 7 months ago

I had the same problem at a customer of mine. He has two WANs, one fiber and one LTE (configured as Backup-WAN - not loadbalancing). He is using pfsense 2.4.4p1.

Using a ssh session i found out, that there was no "default route" (= default gateway) when I checked the routing table with "netstat -r"

What I've done was to add the default route with "route add default xxx.xxx.xxx.xxx" with the package "shellcmd". "xxx.xxx.xxx.xxx" is the ip-address of the gateway, which I've configured as "Tier 1" in the gateway group.

After that the gateway group works as it should!

Hope this helps you too...

#9 Updated by Shawn Bruce 7 months ago

Seeing this issue as well. No default gateway is created.

2.4.4-p1

#10 Updated by Sven Oesterle 7 months ago

Same here on 2.4.5.a.20181221.1732.

#11 Updated by jonathan MANTOVANI 6 months ago

I think i found the bug

file /etc/inc/gwlb.inc

line 1112 replace -> if ($gwgroupitem['gwip'] == $currentdefaultgwip) {
BY-> if (!empty($currentdefaultgwip) AND $gwgroupitem['gwip'] == $currentdefaultgwip) {

#12 Updated by Ioannis Kampolis 6 months ago

jonathan's fix works.

Thank you very much!

#13 Updated by Tiago Alves da Silva 5 months ago

Ioannis Kampolis wrote:

jonathan's fix works.

Thank you very much!

Tried on 2.4.4-RELEASE and the code give me a syntax error. Which version have you tried?

#14 Updated by jonathan MANTOVANI 5 months ago

Normally work on 2.4.4 p1 & p2 for sure, maybe 2.4.4

try this :

replace line 1112 -> if ($gwgroupitem['gwip'] == $currentdefaultgwip) {
BY -> if (!empty($currentdefaultgwip) && ($gwgroupitem['gwip'] == $currentdefaultgwip)) {

if you have a syntax error maybe you have made an error -> double check.

the patch has been submit to pfsense team -> https://github.com/pfsense/pfsense/pull/4034

#15 Updated by Renato Botelho 5 months ago

  • Status changed from New to Feedback
  • Assignee set to Renato Botelho
  • Target version set to 48

PR has been merged, thanks

#16 Updated by Tiago Alves da Silva 5 months ago

Doesn't work on 2.4.4, but on 2.4.4-P1 is fine.

#17 Updated by Tiago Alves da Silva 5 months ago

Renato Botelho wrote:

PR has been merged, thanks

Thanks!

#18 Updated by Jim Pingle 4 months ago

  • Target version changed from 48 to 2.5.0

#19 Updated by Jim Pingle 2 months ago

  • Target version changed from 2.5.0 to 2.4.4-p3

#20 Updated by Constantine Kormashev 2 months ago

2.4.4-p3 does not observe the issue.
WAN_Failover GW Group with 2 links: WAN Tier1 and WAN2 Tier2, set as default GW, reboot does not affect settings and traffic forwarding works fine. I tested the same with disabled WAN Tier1 and it also worked fine.

#21 Updated by Renato Botelho 2 months ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF