Currently, to assign access for an IP VLAN, I have to make a firewall network group and add access rules.
What I tried is the fallowing iptables rule, but for some reason I can’t get that to work and have to go through a couple of steps, add a network group and assign access in the firewall like this:
right now this is set to any in my test lab, but if I was deploying it, the rules would be to red or another zone.
Doesn’t Any --> VLANx punch a hole into the firewall?
How does this ‘set iptables’?
Firewall rules should be defined in the WUI. The firewall modules convert them to iptables commands to add to the tables.
Direct iptables commands must be placed into firewall.local to be permanent. Did you do this?
The networks button in firewall groups (/cgi-bin/fwhosts.cgi)
I wouldn’t think ANY network would bypass the firewall on red , but you wouldn’t use ANY unless the ipfire instance was passing through the vlan.to all zones. But you still have to assign the other zone a either an egress or an ingress VLAN for it to pass the traffic out. on the other zone otherwise traffic would fallow the IP route path. Which is green0.10 (vlan10) to green0 for vlan 10 assigned in the green zone (in bridge mode or not).
But this could be a feature instead of a programming bug since there is user control of the routing of the vlan..
iptables -A FORWARD -i greeen0.10 -o green0 -j ACCEPT
I still have to assign routing outside green with a network firewall group.
This configures a bridge to pass network traffic out through green0 netfilter on iptables from the vlan. Which I found that from RedHat’s VLAN development resource guide.. However its not really needed. since the bridge already has VLAN id 0 for the MAC VLAN system already inside IPFire.
I even tried a direct NAT, but I still have to put in firewall rules in the gui
I still have to configure firewall rules in the gui. Which we might want as far as the end use. But I have to assign a firewall network group which I need to find the iptables command so the user only has to set the firewall rules for the vlan and it will be available in the networks dialog inside firewall rules page once they make the vlan..
I haven’t written any files except the scope in dhcpd.conf.local which when I do that the vlan gets dns through the zone ip (when setting dns to the zone ip in the connected vlan client). Which I am thinking the DHCP server has to be in super scope mode instead of single scope because the only dhcp through a vlan is with the same ip net as the zone. Maybe a dhcp helper could work to do this instead of changing the mode on the DHCP server from single scope to super scope.
The only thingI I haven’t tried is setting DHCP passthrough to VLAN directly using iptables:
iptables -N DHCPVLAN10INPUT
iptables -N DHCPVLAN10OUTPUT
iptables -A INPUT -i green0.10 -j DHCPVLAN10INPUT
iptables -A OUTPUT -i green0.10 -j DHCPVLAN10OUTPUT
Which theoretically I can reduce coding of adding the VLAN (after adding the dhcp pool in the dhcpd.conf.local ) to just:
Then configure firewall access in the WEB gui which I imagine there is a file I could just insert the network without having to go through the webgui at fwhosts.cgi which later on in a few hours I’ll get home to look at it.
i think it still has to do with a mode that is set with the DHCP server. Because even trying:
Doesn’t work. as DHCPd will only assign one network to the interface even though the interface has two networks. and its already assigned.. On orange, it would assign dhcp on the vlan, but Orange is the DMZ and not the client network zone.
But I guess that wouldn’t be a big deal. to require staatic on a lan because you could run an external dhcp server in the vlan but I seen about half of them static ip configured in the field too. So I think it is not much of a big deal for it not having DHCP on IP VLANS in IPFire.
Why is the VLan tag included in ipfire rules when fixed IP addresses and the networks have already been defined? As far as I understand, the Ipfire interfaces are configured as trunk ports, so no VLan tags in the rules are necessary.
I’m in the process of creating a IPVLAN system that will go along with the existing system which is MACVLAN type. That normally is used for network trunking the zones over one port. That is why its limited to one vlan on the port in the upper menu.
but if you want a zone (that could have more than one port) then you would use IPVLAN and then you can assign up to 4092 VLANS (VLAN 0 is reserved and 1 is normal net) That you assign a IP network pool to the vlan. .
The dhcp server is in single scope mode so it will assign only on the interface address and its pool if the pool is defined. If you assign the orange an iIPVLAN, the vlan has to be the same ip range as the interface, then DHCP would work in that VLAN only.
I’m just can’t remember the mode/option numbers that get assigned to dhcp to convert to super scope mode. But static assigning the clients might be a better choice for iplans.
There is other types of VLANS but I haven’t seen anyone request them like IPSECVLAN where you tie across the internet like ipsec with SSL but in VLAN.
At first, I thought this was nonsense, since VLANs are used to create separate segments within an address range by assigning physical ports.
For example, I want to combine a blue network from a Wi-Fi card with several access points (APs) via the green wired network, but I want to keep both completely separate. If you think a little bigger and consider the DHCP scope configurations, there are other possibilities for setting up a network in conjunction with QoS.
For example, all tunnels on port 22 are part of a VLAN with QoS privileges, and the IPSEC connection goes through that tunnel.
You could also use a superscope to route all DNS queries from a subdivided address range to the DNS server via a separate scope VLAN. For example, you could have a DHCP scope for fixed IP assignments and a DHCP scope for the dynamic address range. The superscope would pass all over the DNS server and gateway for the complete dhcp range.
Just a heads-up: in ipfire, the orange area doesn’t have a DHCP server, so you can only set up a fixed assignment using MAC and the VLAN specified there. I don’t think the DHCP server on green or blue can just grab a superscope here because of the fixed DMZ zone.
Well its all how vlantables are applied is what you get the desired outcome. But the way iptables were applied is the zones are separate networking scopes as an ebtable entry sharing the same iptable network universe. The way I figured out the method I want to propose is a seperate vlan table per ebtable entry so that the traffic still is inspected at the exit point of the network zone’s ebtable.. One of the common practices of vlans is the network isolation so any machine arbitrarily connected to the network can not access anything. This is one of the security implementations of it Sisco likes to boast about vlans. QOS is only a small factor and a feature already built into ipvlans since they collapse empty data on each packet. Hence that is why it can assign all vlan channels (0-4095) through while servicing all connections at maximum throughput. Of course, vlan 0 and 4095 is reserved for protocal forwarding and vlan 1 is not tagged into a vlan.. each network zone has these separate because the endpoint is a different ebtable (green, blue, orange, red) so to patch arcross from green to blue on a vlan it would still need to go through iptables connection tracking route and of course an entry on that table.
Because of the mode the DHCP server is in, only one scope or commonly known as ip pool can be administered. Now I haven’t had much time to set a bigger netmask on the dchp server and see what happens, but I imagine I could get a 10.0.0.xxx and a 10.0.1.xxx net however the ip schemes are not separated unless you limit the dhcp pool size and reserve the VLANs IP addresses in the separate net. Theoretically that should work since the gateway and netmask would be broadcasted. Positive thing is I wouldn’t have to make a firewall network group, however, the idea of limiting the vlan by network mask would be lost and keeping the ip range specific to the vlan for organizational purposes as well since all ip addresses in the netmak would be valid and would have to rely on address reservation to keep it organized.
Just been busy with a lot of things and paid programming and other computer work has been eating up my time lately. But I have half the zoneconf.cgi re-written but don’t want to submit it partially finished. But since there are 4 to 6 ways of accomplishing the code side of it I’ve been able to reduce it to 5 lines of code. But I’m still looking at ways to display it after one has been made too.
I found the file I need to add the firewall network group. But I’ve been busy with programming work and domestic things like my 70+ year old iron drain pipe in the wall that decided to disintegrate on me and made a big water mess in the house.
Wouldn’t it be sufficient in principle to configure the area you use and use the remaining, unused local IP area for a VLAN that is simply isolated from everything and cannot be accessed anywhere, so that a foreign computer in your own network has no way of reaching anything?
Configurable switches also offer the option of assigning fixed MAC addresses to ports so that no other device can be connected, or of completely disabling free ports.
An unused VLAN is just one of many ways to let intruders run into an empty space.
I suppose, but vlan is a weak security measure compared to just blocking a network range with iptables. Because mac addresses can be cloned. Managed switches don’t have netfilter capability and only can assign points in, out, and through by mac and vlan tag. For the common layer 2 managed switch.
The purpose of this vlan addition is to make the virtual egress point to the iptable’s net filter. So there is no physical port that is getting configured and the physical ports on the ipfire server is just passing through the tagged data that was ingress to vlan by the managed switch. There is already a MACVLAN system but that is a different functionality and you have to assign it exclusively in that zone that vlan # on that port. Plus meet the hardware requirement of the ethernet interface supporting VLAN tagging/untagging.
The after effects of ipfire’s iptables causes each zone to have separate vlan universe and does not network across zones unless both van # ip net in the zone (green, blue, etc) are set with the same IP address net. Traffic to WAN is controlled by Iptables with net filter rules.
Now, for like making a managed switch os, you have to meet hardware compatibility because the ethernet interface has to support VLAN tagging & untagging functions. Which just like all other managed switches wouldn’t use netfilter which is a firewall function.
