VLAN on Edge Router But IpFire As Internal Firewall Needs To Route?
My IpFire box is an internal firewall, connected to and edge router, so my Red0 interface is connected to a ‘LAN’ port on the edge router. And of course IpFire Green0 interface is acting as default gateway for Green Zone. DNS and DHCP are only in the Green Zone, everything is working as expected.
My edge router supports VLANs, so I was thinking I could create a VLAN there, and have the IpFire box handle all the outbound traffic from the core (physical network) and the VLAN. The goal is to establish a virtual, say blue rail, on top of the green rail, i.e. via the VLAN.
The question is, do I have to create any special rules or logic for this to work? Thinking IpFire box will not care about any VLAN tagging explicitly or am I wrong? All the tagging will be done by the edge router, passed transparently across edge router ‘LAN’ port to the Red0 interface to the Green0 interface, and visa versa?
vLANs are a tool for using the same hardware for more things. Or networks.
Do you have 12 subnets to transport to the other side of a network cable/fiber? Without vLANs you need 12 “cables” and 12 switch ports times 2 (one for takeoff, one for landing).
With vLANs, if the transport capability is enough, you need only 1. Or 4, if you need more bandwith, but neverthless not two ports and one cable for any of the subnets.
A Router/Firewall can use vLANs as network interfaces, and create “more networks and subnets than actually availeble ports”, but anyway won’t change the base ground setup of what is WAN/Red and what is LAN/Green or WLAN/Blue or DMZ/Orange.
vLANs are… meaningless for routing.
Routing rely on TCP/IP and this software (version 4 or version 6 do not matter) do not give a damn if it’s routing on ATM, Ethernet, Wireless Ethernet, Fiber, FC, UMTS. Underlying OS must know how to deal with that silicon (it’s called driver) or software (IPSec, OpenVPN, Wireguard… vLAN) and it will deliver packages as TCP/IP (and routing rules) request.
Not sure you understood my question, I simply want the defined VLAN as defined on my edge router to be visible both in Red0 and Green0, as a VLAN. I don’t have the option to dedicate physical resources, i.e. ports or cables to physical isolation in my home environment.
I realize this is not optimal and has a risk of a side attach of the VLAN, but I still want to provide isolation that a VLAN will provide.
Thus the question is, how can I configure IpFire (which is ONLY functioning as an internal firewall) not as a WAN/LAN router to allow visibility of the VLAN that is actually defined on the edge router.
Physical and current function…
Edge Router → DMZ (Red) → IpFire → LAN (Green)
With VLAN…
Edge Router → DMZ (Red) → IpFire → LAN (Green)
Edge Router/VLAN → DMZ (Red)/VLAN → IpFire → LAN (Green)/VLAN
Currently when I create the VLAN on the Edge Router, I cannot connect nor ping the Default GW of the VLAN behind the IpFire (internal) Fire wall. IpFire seems to be ignoring or stripping the VLAN tagging? Or otherwise not passing through the applicable tagging. I am not, or so I believe, not asking the IpFire device to do any routing per se, but if I am wrong on that, that would explain why the VLAN does not seem to be visible on Green (LAN) segment.
Either way, something is blocking the VLAN from working behind the IpFire firewall, which was a surprise, I was expecting the VLAN to just be transparently visible in Green zone, as it is visible in the Red zone now.
You would need to run setup and select
Red blue green.
Then add vlan tag to red and green for vlan blue from the Wui
Then bridge the blue vlans
Reboot.
Do not know if this will work
Just seams Like a bad idea.
You IPfire would be better served as your edge router.
True, it might be easier to let IpFire function as the edge router, but at this point in time that is not an option. This is all testing at this point.
What I may do, is create a VLAN at the edge router that would only service the Red Zone. And then create a different VLAN on the IpFire, that serves only Green Zone (i.e. create virtual Blue Zone).
This would seem to be a better model more inline with the IpFire applicable design…
Thinking of possible way to do what is desired… And, I the edge router actually has an available physical port, so no need for a VLAN in the Red Zone, which I believe would be needed…
Edge Router LAN1 → (Pick Color?) Zone → External Facing NAS (VPN Wire Guard)
Edge Router LAN2 → Red Zone → IpFire → Green Zone LAN → Various Devices
Edge Router LAN2 → Red Zone → IpFire → Blue Zone VLAN, WiFi Access Points
Edge Router LAN2 → Red Zone → IpFire → Orange Zone VLAN, IoT Devices
(Existing) Edge Router LAN3 → Fiber (Bridge/Route) To other Switch (and infrastructure)
This would let me do (logical/virtual) device isolation to an extent between Green, Orange and Blue zones, respectively.
The limitations I have as noted above, I cannot at this time add to the physical network, cannot replace the edge router (WAN/LAN) with the IpFire device.
Clearly, If I had the physical ports on the IpFire device, I would set Orange and Blue to use physical ports. If I could add physical networks, would do for Blue and Orange zones.
You already have the capability to deliver isolation between IPFire zones, using your IPFire. If you want to isolate a specific device from the zone where it sits… you can install firewall on that device (if possible) or you have to put it outside that zone, into another.
As far as I can read here as your goals, I cannot completely understand what you’re trying to achieve, therefore… vLANs currently seems unnecessary to me because I cannot find the point when vLANS could be useful.
This picture come from a network diagram example of draw.io. Assume that all the sections are in different buildings.
Goal is to allow work between section 2 and 4 like being a unique network, while Section 1 and 3 acting as separate entities.
(diagram is lacking details and devices on purpouse)
If a geographic (internet) connection is not necessary and the core network is capable enough, vLANs could be used for realise this logical layout
while section 2 and 4 could have only a couple of cables/fibers to connect them, and being a subnet and have only one set of firewall rules.
If a geographical connection is necessary between buildings, AFAIK the only answer is MPLS between section 2 and section 4.
vLANs are a tools to translate in reality logical network diagrams.
They “only” helps saving ports and cables… or have more when phisically they are not enough.
Like multi-SSID Access Points: they have a 2 RJ45 ports (tops) but more often only one, and if you need to deliver 4-5 SSIDs/subnets… vLANS are the only way to provide the connection between wireless devices and the remaining subnet.
I think the issue is that the IPFire being discussed only has two network interfaces, so only red and green but the desire is to also have blue and orange.
So with an IPFire with two network interfaces then a vlan can be used with the green interface to have a blue or orange network.
However with only two network interfaces you can not do both blue and orange as with the current code base of IPFire-2.x you can only have one vlan per network interface as mentioned in https://www.ipfire.org/docs/configuration/network/zoneconf
Ah, thank for the reminder on that limitation with the current code base. After reading your comment, I realized, I had forgotten the single VLAN limit per interface.
Given my edge router can have multiple VLANs, where the IpFire hardware is limited, and IpFire its-self is limited, that is why, at the initial question, was asking if there was a way to ‘pass’ the VLANs through the IpFire device.
Since I cannot change the physical network, behind where the IpFire device is, to do exactly what I want, I really need to use a device that can support multiple VLANs by design.
Or I live with the limits as noted above, i.e. only Orange Or Blue as an IpFire based VLAN, not both.
Just curious, is support for more VLANs on the development time line for IpFire? Don’t get me wrong, I realize this a big ask/expectation, when physical port isolation really is the best practice.
That is part of the plan for IPFire-3.x which is a from scratch complete re-build of IPFire. It is still some way away as the IPFire dev team is very small and also has to support any major bugs found on IPFire-2.x and support and fix any security issues found on IPFire-2.x etc, etc.
