Page MenuHomeVyOS Platform
Create Task
Maniphest T2251

VRF communication breaks when utilizing zone-based firewalling
Open, NormalPublicBUG
Actions

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
Search...

Event Timeline

Coopercentral created this task.Apr 8 2020, 11:57 PM
pasik added a subscriber: pasik.Apr 9 2020, 7:47 AM
Viacheslav added a parent task: T2579: The root task for VRF features.Jun 10 2020, 12:55 PM
Raeven added a subscriber: Raeven.Oct 19 2020, 9:14 PM
Gunni added a subscriber: Gunni.Oct 21 2020, 6:20 PM
vindenesen added a subscriber: vindenesen.Apr 30 2021, 9:47 AM
mbailey added a subscriber: mbailey.May 15 2021, 5:02 PM
janegil added a subscriber: janegil.May 19 2021, 3:28 PM
yun added a subscriber: yun.Jul 28 2021, 8:05 PM
krox2 added a subscriber: krox2.Aug 27 2021, 1:25 PM
c-po added a project: VyOS 1.4 Sagitta.Aug 27 2021, 5:15 PM
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).
c-po added a parent task: T2199: Rewrite firewall in new XML/Python style.
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.
n.fort added a subscriber: n.fort.Oct 31 2021, 11:40 AM

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
syncer edited projects, added VyOS 1.3 Equuleus (1.3.0); removed VyOS 1.3 Equuleus.Nov 6 2021, 11:25 AM
Unknown Object (User) added a subscriber: Unknown Object (User).EditedNov 12 2021, 9:19 AM

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.

danhusan added a subscriber: danhusan.Dec 18 2021, 12:59 PM
eronlloyd added a subscriber: eronlloyd.Feb 21 2022, 10:57 AM
syncer edited projects, added VyOS 1.3 Equuleus (1.3.3); removed VyOS 1.3 Equuleus (1.3.0).Aug 29 2022, 7:05 AM
DerEnderKeks added a subscriber: DerEnderKeks.Feb 10 2023, 10:07 PM
c-po added a subscriber: c-po.May 21 2023, 7:05 PM

Please re-test with latest 1.4 release as the firewall was moved from iptables -> nftables

ganawaj added a subscriber: ganawaj.Jun 11 2023, 8:05 PM

This bug is still present in the latest 1.4 rolling release

Viacheslav added a subscriber: Viacheslav.EditedJun 12 2023, 9:34 AM
In T2251#150145, @ganawaj wrote:

This bug is still present in the latest 1.4 rolling release

@ganawaj add dev TEST

set zone-policy zone SERVER interface eth1
set zone-policy zone SERVER interface TEST
Coopercentral added a comment.Jun 14 2023, 12:14 PM

From my testing, all traffic that originates from an interface attached to a VRF, will show the source interface as the VRF master interface, regardless of the zone attached to that interface. This will make it difficult to segment traffic between interfaces attached to the same VRF. For example:

eth0 - "WAN" zone
eth1 - "LAN" zone
eth2 - "DMZ" zone

Say each of the above are attached to "TEST" VRF. You'd need to assign the "TEST" VRF master interface to a zone - for the sake of example we could create a dedicated zone "TEST-VRF" and assign the "TEST" master VRF interface. Any traffic originated from eth0, eth1, or eth2 will show the "TEST-VRF" as the source zone. Just wondering if there's any plan to fix this, so that the firewall will see the actual physical interface as the source interface as opposed to the VRF master interface, thus using the actual zone the interface is attached to. Despite being attached to a VRF, it would be nice to have the normal "WAN-to-LAN", "LAN-to-WAN", "DMZ-to-LAN" etc. zone-pair directions.

syncer edited projects, added VyOS 1.3 Equuleus (1.3.4); removed VyOS 1.3 Equuleus (1.3.3).Jul 12 2023, 9:42 PM
syncer edited projects, added VyOS 1.3 Equuleus (1.3.5); removed VyOS 1.3 Equuleus (1.3.4).Aug 25 2023, 9:30 PM
syncer edited projects, added VyOS 1.3 Equuleus (1.3.6); removed VyOS 1.3 Equuleus (1.3.5).Dec 17 2023, 11:37 PM
Viacheslav triaged this task as Normal priority.Jan 20 2024, 12:52 AM
syncer edited projects, added VyOS 1.3 Equuleus (1.3.7); removed VyOS 1.3 Equuleus (1.3.6).Feb 10 2024, 9:17 AM
dmbaturin added a project: Restricted Project.Feb 15 2024, 11:28 AM
dmbaturin edited projects, added VyOS 1.4 Sagitta (1.4.0-epa1); removed VyOS 1.4 Sagitta.Feb 15 2024, 3:05 PM
hsw0 added a subscriber: hsw0.Mar 12 2024, 10:28 AM