Page MenuHomeVyOS Platform

VRF communication breaks when utilizing zone-based firewalling
Open, Requires assessmentPublicBUG

Description

Installed the most recent rolling release (1.3-rolling-202004070629). Testing out the VRF implementation with zone-based firewalling. Attaching "eth0" (default VRF) to "MGMT" and "eth1" (TEST VRF) to "SERVER", and "LOCAL" for the local-zone. I create firewall names with only "rule 1 action accept", just for testing purposes. Once I commit, I am no longer able to communite with anything behind the SERVER zone (TEST VRF). When I try to ping the eth1 interface address, sourcing from the "TEST" vrf, it shows "operation not permitted", thus getting blocked by the firewall local-zone. See config below.

set firewall name local-out rule 1 action 'accept'
set firewall name mgmt-to-local rule 1 action 'accept'
set firewall name mgmt-to-server rule 1 action 'accept'
set firewall name server-to-local rule 1 action 'accept'
set firewall name server-to-mgmt rule 1 action 'accept'
set interfaces ethernet eth0 address '172.16.1.90/24'
set interfaces ethernet eth1 address '172.16.2.90/24'
set interfaces ethernet eth1 vrf 'TEST'
set interfaces loopback lo
set protocols static route 0.0.0.0/0 next-hop 172.16.1.1
set protocols vrf TEST static route 0.0.0.0/0 next-hop 172.16.2.1
set service ssh
set system config-management commit-revisions '100'
set system console device ttyS0 speed '115200'
set system host-name 'vyos'
set system login user vyos authentication encrypted-password '$6$umXxrvZsb9nMOb0W$iBIzrXZUm4Ysa8fDplNALXvOHYnYYx9aBiv2UN.xkIn5C03r4s3g82apczZxMk8OZFxRxvGsU5VkaIDatuHy1.'
set vrf name TEST table '100'
set zone-policy zone LOCAL default-action 'drop'
set zone-policy zone LOCAL from MGMT firewall name 'mgmt-to-local'
set zone-policy zone LOCAL from SERVER firewall name 'server-to-local'
set zone-policy zone LOCAL local-zone
set zone-policy zone MGMT default-action 'drop'
set zone-policy zone MGMT from LOCAL firewall name 'local-out'
set zone-policy zone MGMT from SERVER firewall name 'server-to-mgmt'
set zone-policy zone MGMT interface 'eth0'
set zone-policy zone SERVER default-action 'drop'
set zone-policy zone SERVER from LOCAL firewall name 'local-out'
set zone-policy zone SERVER from MGMT firewall name 'mgmt-to-server'
set zone-policy zone SERVER interface 'eth1'

Details

Difficulty level
Hard (possibly days)
Version
1.3
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Behavior change
Issue type
Bug (incorrect behavior)

Related Objects

Event Timeline

c-po changed Difficulty level from Unknown (require assessment) to Hard (possibly days).
c-po changed Is it a breaking change? from Unspecified (possibly destroys the router) to Behavior change.
c-po set Issue type to Improvement (missing useful functionality).
erkin changed Issue type from Improvement (missing useful functionality) to Bug (incorrect behavior).Aug 30 2021, 7:18 AM
erkin removed a subscriber: Active contributors.

Bug still present in 1.3.0-epa2 version.

Same config, without firewall:

vyos@vyos# run ping 172.16.2.90 vrf TEST
PING 172.16.2.90 (172.16.2.90) 56(84) bytes of data.
64 bytes from 172.16.2.90: icmp_seq=1 ttl=64 time=0.035 ms
64 bytes from 172.16.2.90: icmp_seq=2 ttl=64 time=0.074 ms

Then, after applying zone based firewall:

vyos@vyos# run ping 172.16.2.90 vrf TEST
PING 172.16.2.90 (172.16.2.90) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted

Adding set zone-policy zone SERVER interface SERVER to the presented test case should solve the issue. This is because the traffic needs to pass both eth1 and its associated VRF "master" interface, in this case TEST.

Not sure whether some custom syntax/logic should be implemented to special case VRF interfaces in the zone based firewall.

Edit: Another option might be to create a zone which contains the VRF master interface and setting the zone policy to default-action accept. Example:

set zone-policy zone VRF-TEST interface TEST
set zone-policy zone VRF-TEST default-action accept

This would effectively restore the previous behavior while maintaining maximum flexibility.
Note that zone-policy default-action accept is not currently implemented.