Project

General

Profile

Actions

Regression #12949

closed

The ruleset is not regenerated after assigning an interface

Added by Steve Wheeler 3 months ago. Updated 27 days ago.

Status:
Resolved
Priority:
Normal
Assignee:
Viktor Gurov
Category:
Interfaces
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
22.05
Release Notes:
Default
Affected Version:
2.6.x
Affected Architecture:
All

Description

In some circumstances the ruleset is not reloaded or regenerated after re-assigning an interface.

For example after reassigning the WAN from igb0 to lagg0 in the webgui and saving that the WAN interface is correctly switched and brings up an IP as shown in ifconfig:

lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        description: WAN
        options=e138bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC,VLAN_HWFILTER,RXCSUM_IPV6,TXCSUM_IPV6>
        ether 00:90:7f:da:44:72
        inet6 fe80::290:7fff:feda:4472%lagg0 prefixlen 64 scopeid 0x11
        inet 172.21.16.183 netmask 0xffffff00 broadcast 172.21.16.255
        laggproto lacp lagghash l2,l3,l4
        laggport: ix0 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
        laggport: ix1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
        groups: lagg
        media: Ethernet autoselect
        status: active
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

But the firewall is not usable because ruleset in place is still referencing igb0:

[2.6.0-RELEASE][root@m470-3.stevew.lan]/root: cat /tmp/rules.debug
set limit table-entries 400000
set optimization normal
set limit states 397000
set limit src-nodes 397000

#System aliases

loopback = "{ lo0 }" 
WAN = "{ igb0 }" 
LAN = "{ igb1 }" 

That can also be seen in the running rulset:

[2.6.0-RELEASE][root@m470-3.stevew.lan]/root: pfctl -sr | grep igb0
scrub on igb0 inet all fragment reassemble
scrub on igb0 inet6 all fragment reassemble
pass in quick on igb0 proto udp from any port = bootps to any port = bootpc keep state label "allow dhcp client out WAN" ridentifier 1000000561
pass out quick on igb0 proto udp from any port = bootpc to any port = bootps keep state label "allow dhcp client out WAN" ridentifier 1000000562
pass in quick on igb0 inet6 proto udp from fe80::/10 port = dhcpv6-client to fe80::/10 port = dhcpv6-client keep state label "allow dhcpv6 client in WAN" ridentifier 1000000563
pass in quick on igb0 proto udp from any port = dhcpv6-server to any port = dhcpv6-client keep state label "allow dhcpv6 client in WAN" ridentifier 1000000564
pass out quick on igb0 proto udp from any port = dhcpv6-client to any port = dhcpv6-server keep state label "allow dhcpv6 client out WAN" ridentifier 1000000565
pass in quick on igb0 inet all flags S/SA keep state label "USER_RULE: Allow all ipv4+ipv6 via pfSsh.php" ridentifier 1647298900
pass in quick on igb0 inet6 all flags S/SA keep state label "USER_RULE: Allow all ipv4+ipv6 via pfSsh.php" ridentifier 1647298900
[2.6.0-RELEASE][root@m470-3.stevew.lan]/root: pfctl -sr | grep lagg0
[2.6.0-RELEASE][root@m470-3.stevew.lan]/root: 

Tested using a DHCP WAN where both igb0 and lagg0 are pulling leases from the same server.

Tested in 2.6. It does not happen in 2.5.2.

Actions #1

Updated by Steve Wheeler 3 months ago

Logs from a 2.5.2 VM where I reassigned WAN from em0 to vtnet0 and am able to login at the new IP imediately:

Mar 16 16:00:34     php-fpm     358     /interfaces_assign.php: Shutting down Router Advertisment daemon cleanly
Mar 16 16:00:34     check_reload_status     386     rc.newwanip starting vtnet0
Mar 16 16:00:34     php-fpm     358     /interfaces_assign.php: calling interface_dhcpv6_configure.
Mar 16 16:00:34     php-fpm     358     /interfaces_assign.php: Accept router advertisements on interface vtnet0
Mar 16 16:00:34     php-fpm     358     /interfaces_assign.php: Starting rtsold process
Mar 16 16:00:35     php-fpm     357     /rc.newwanip: rc.newwanip: Info: starting on vtnet0.
Mar 16 16:00:35     php-fpm     357     /rc.newwanip: rc.newwanip: on (IP address: 172.21.16.167) (interface: []) (real interface: vtnet0).
Mar 16 16:00:35     php-fpm     357     /rc.newwanip: rc.newwanip called with empty interface.
Mar 16 16:00:35     php-fpm     357     /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - -> 172.21.16.167 - Restarting packages.
Mar 16 16:00:35     check_reload_status     386     Reloading filter
Mar 16 16:00:35     check_reload_status     386     Starting packages
Mar 16 16:00:36     php-fpm     358     /interfaces_assign.php: Default gateway setting Interface WAN_DHCP Gateway as default.
Mar 16 16:00:36     php-fpm     358     /interfaces_assign.php: Gateway, none 'available' for inet6, use the first one configured. 'WAN_DHCP6'
Mar 16 16:00:36     check_reload_status     386     Restarting ipsec tunnels
Mar 16 16:00:36     php-fpm     357     /rc.start_packages: Restarting/Starting all packages.
Mar 16 16:00:40     check_reload_status     386     updating dyndns wan
Mar 16 16:00:40     check_reload_status     386     Syncing firewall
Mar 16 16:00:40     php-fpm     358     /interfaces_assign.php: Creating rrd update script
Mar 16 16:00:40     kernel         arprequest: cannot find matching address
Mar 16 16:00:40     kernel         arprequest: cannot find matching address
Mar 16 16:00:41     kernel         arprequest: cannot find matching address
Mar 16 16:00:42     login     81025     login on ttyv0 as root
Mar 16 16:00:43     kernel         arprequest: cannot find matching address
Mar 16 16:00:45     kernel         arprequest: cannot find matching address
Mar 16 16:00:49     rc.gateway_alarm     85955     >>> Gateway alarm: WAN_DHCP (Addr:172.21.16.1 Alarm:1 RTT:.619ms RTTsd:.121ms Loss:22%)
Mar 16 16:00:49     check_reload_status     386     updating dyndns WAN_DHCP
Mar 16 16:00:49     check_reload_status     386     Restarting ipsec tunnels
Mar 16 16:00:49     check_reload_status     386     Restarting OpenVPN tunnels/interfaces
Mar 16 16:00:49     check_reload_status     386     Reloading filter
Mar 16 16:00:49     kernel         arprequest: cannot find matching address
Mar 16 16:00:50     php-fpm     358     /rc.openvpn: Gateway, none 'available' for inet, use the first one configured. 'WAN_DHCP'
Mar 16 16:00:50     php-fpm     358     /rc.openvpn: Gateway, none 'available' for inet6, use the first one configured. 'WAN_DHCP6'
Mar 16 16:00:57     kernel         arprequest: cannot find matching address
Mar 16 16:00:59     php-fpm     358     /index.php: Successful login for user 'admin' from: 172.21.16.243 (Local Database)
Mar 16 16:01:12     kernel         arprequest: cannot find matching address
Mar 16 16:01:28     kernel         arprequest: cannot find matching address
Mar 16 16:01:44     kernel         arprequest: cannot find matching address
Mar 16 16:01:59     kernel         arprequest: cannot find matching address 

Logs from 2.6 showing the same change (not the same VM though):

Mar 16 19:50:47     php-fpm     412     /interfaces_assign.php: Shutting down Router Advertisment daemon cleanly
Mar 16 19:50:47     check_reload_status     450     Linkup starting vtnet0
Mar 16 19:50:47     kernel         vtnet0: link state changed to UP
Mar 16 19:50:48     check_reload_status     450     Reloading filter
Mar 16 19:50:50     check_reload_status     450     rc.newwanip starting vtnet0
Mar 16 19:50:50     php-fpm     412     /interfaces_assign.php: calling interface_dhcpv6_configure.
Mar 16 19:50:50     php-fpm     412     /interfaces_assign.php: Accept router advertisements on interface vtnet0
Mar 16 19:50:50     php-fpm     412     /interfaces_assign.php: Starting rtsold process
Mar 16 19:50:51     php-fpm     413     /rc.newwanip: rc.newwanip: Info: starting on vtnet0.
Mar 16 19:50:51     php-fpm     413     /rc.newwanip: rc.newwanip: on (IP address: 172.21.16.186) (interface: []) (real interface: vtnet0).
Mar 16 19:50:51     php-fpm     413     /rc.newwanip: rc.newwanip called with empty interface.
Mar 16 19:50:51     check_reload_status     450     Reloading filter
Mar 16 19:50:51     php-fpm     413     /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - -> 172.21.16.186 - Restarting packages.
Mar 16 19:50:51     check_reload_status     450     Starting packages
Mar 16 19:50:52     php-fpm     412     /interfaces_assign.php: Gateway, none 'available' for inet, use the first one configured. 'WAN_DHCP'
Mar 16 19:50:52     php-fpm     412     /interfaces_assign.php: Default gateway setting Interface WAN_DHCP Gateway as default.
Mar 16 19:50:52     php-fpm     412     /interfaces_assign.php: Gateway, none 'available' for inet6, use the first one configured. 'WAN_DHCP6'
Mar 16 19:50:52     check_reload_status     450     Restarting IPsec tunnels
Mar 16 19:50:52     php-fpm     413     /rc.start_packages: Restarting/Starting all packages.
Mar 16 19:50:55     check_reload_status     450     updating dyndns wan
Mar 16 19:50:55     php-fpm     412     /interfaces_assign.php: Configuration Change: admin@172.21.16.243 (Local Database): Interfaces assignment settings changed
Mar 16 19:50:55     check_reload_status     450     Syncing firewall
Mar 16 19:50:55     php-fpm     412     /interfaces_assign.php: Creating rrd update script
Mar 16 19:50:55     kernel         arprequest: cannot find matching address
Mar 16 19:50:56     kernel         arprequest: cannot find matching address
Mar 16 19:50:57     kernel         arprequest: cannot find matching address
Mar 16 19:50:59     kernel         arprequest: cannot find matching address
Mar 16 19:51:01     kernel         arprequest: cannot find matching address
Mar 16 19:51:05     kernel         arprequest: cannot find matching address
Mar 16 19:51:13     kernel         arprequest: cannot find matching address
Mar 16 19:51:28     kernel         arprequest: cannot find matching address
Mar 16 19:51:44     kernel         arprequest: cannot find matching address
Mar 16 19:52:00     kernel         arprequest: cannot find matching address
Mar 16 19:52:15     kernel         arprequest: cannot find matching address 

Actions #2

Updated by Marcos Mendoza 3 months ago

I was able to reproduce this on 2.6 with a default config.

Actions #3

Updated by Steve Wheeler 3 months ago

Also seeing this in:

2.7.0-DEVELOPMENT (amd64)
built on Mon Mar 14 19:29:13 UTC 2022
FreeBSD 12.3-STABLE

And:

22.05-DEVELOPMENT (amd64)
built on Wed Mar 16 06:19:09 UTC 2022
FreeBSD 12.3-STABLE

Actions #4

Updated by Viktor Gurov 3 months ago

  • Assignee set to Viktor Gurov
Actions #5

Updated by Jim Pingle 3 months ago

  • Status changed from New to Pull Request Review
Actions #6

Updated by Viktor Gurov 3 months ago

  • Status changed from Pull Request Review to Feedback
Actions #7

Updated by Viktor Gurov 3 months ago

  • % Done changed from 0 to 100
Actions #8

Updated by Steve Wheeler 27 days ago

  • Status changed from Feedback to Resolved

Confirmed this no longer happens in current 2.7 snapshots. The running ruleset is updated immediately when re-assigning the WAN.

Tested:

2.7.0-DEVELOPMENT (amd64)
built on Wed Jun 01 06:12:27 UTC 2022
FreeBSD 12.3-STABLE

Actions

Also available in: Atom PDF