I've added two more rules at the end, to effectively place the "RELATED,ESTABLISHED" rule above the rules we are entering or you could get problem with any further manual rules you enter.

Brrrrr,

What an annoying piece of forum software this is...
It is built by people who don't know what intuitive is.

Probably made by the same people who made the modern ClearOS web interface, still search myself silly to find stuf.
I still long to say back to the Clarkconnect interface.

Hi Nick, I'm not a new forum user, I started just after version 1 of Clarckconnect.
But something went wrong with my data, so I signed up again.

That I asked my question twice, is because of the bad forum software.
I pressed the "send" button and it took at least 10 seconds before I got a response.
I'm behind four big screens here and if the reaction takes so long, your eyes will automatically go to one of the other four screens, because i have more work to do.
And I thought I already saw something from the corner of my eye, so that was the short message that the first question is always judged first.

But just leave that message on the screen and show it immediately afther pushing te send button, and not after 10 seconds.
In case you think I have a slow Internet connection, it is 400mBit down and 40MmBit, up fast enough for a forum topic?
Creating forum topics on EEVBLOG is no problem at all also on a American Server.

And now to the last about this forum and ClearOS website, why all the tracking that happens there.
14 items I see in NoScript, 7 trackers and uBlock reports 11 items...
Why so data greedy?

But let's go back to network problem :-)
Thanks for al the work!

I have already solved a part based on your comment, I have now made a "Hot" LAN for one of the VLANs.
And of course I ran into a bug that this didn't work, removed this VLAN and then created it again and when I created it I immediately chose for a HOT LAN and that worked.
For now this is enough, with this I can isolate the IP segment for media equipment sufficiently in their VLAN.

It is so practical, if you can use a matrix in the ClearOS web interface to specify which LAN or VLAN can exchange data with each other.
I find it strange that this is still not built into ClearOS, why else would you use VLAN or separate IP segments if they can all talk to each other by default.

For now, I am not going to modify Server network scripts in a production Server.
I will set ClearOS as a virtual machine to test with the modifications you proposed.

And I would like to thank you once again for your commitment!

Kind regards,
Bram

To isolate LAN from each other, create a file /etc/clearos/firwall.d/05-isolatedlans and in it put:

#!/bin/bash



# Source networking configuration.

. /etc/clearos/network.conf



# Bail if not ipv4

if [ "$FW_PROTO" != 'ipv4' ]; then

    return 0

fi



if [ -n "$LANIF" ]; then



    # Add isolation rules

    for iLAN in $LANIF; do

        for oLAN in $LANIF; do

            if [ "$iLAN" != "$oLAN" ]; then

                $IPTABLES -I FORWARD -i $iLAN -o $oLAN -j DROP

            fi

        done

    done



fi



# Really all the above should be inserted below the existing "RELATED,ESTABLISHED" rule

#  but this is a dirty fix. Delete the existing and add a new one.

$IPTABLES -D FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

$IPTABLES -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

This is not proving so easy. HotLAN's differ from LAN's in that they are not allowed to access the server, so you almost need the concept of Isolated LAN's which are like LAN's but can't talk to each other. I've updated the script for HotLANs:

#!/bin/bash



# Isolated LANs are like LAN's but cannot talk to each other

# Isolated LANs are like HotLAN's but can talk to ClearOS

# Can take the value of "no" (treat like HotLAN) or "yes" allow the HotLAN to talk to ClearOS

IsolatedLANs="yes"



# Source networking configuration.

. /etc/clearos/network.conf



# Bail if not ipv4

if [ "$FW_PROTO" != 'ipv4' ]; then

    return 0

fi



if [ -n "$HOTIF" ]; then



    # Clear all HotLAN rules

    for HotLAN in $HOTIF; do

        RULE_IDS=$($IPTABLES -nv --line-numbers -L FORWARD |\

            grep " $HotLAN *0\.0\.0\.0\/0 *0\.0\.0\.0\/0" | awk '{ print $1 }' | sort -rn)

        if [ -n "$RULE_IDS" ]; then

            for rule_id in $RULE_IDS; do

                $IPTABLES -D FORWARD ${rule_id}

            done

	    fi

    done

	

    # Add replacement HotLAN rules

    for HotLAN in $HOTIF; do

        if [ -n "$EXTIF" ]; then

            for WANIF in $EXTIF; do

                $IPTABLES -A FORWARD -i $HotLAN -o $WANIF -j ACCEPT

            done

        fi

        if [ "$IsolatedLANs" = "yes" ] ; then

                $IPTABLES -A INPUT -i $HotLAN -j ACCEPT

                $IPTABLES -A OUTPUT -o $HotLAN -j ACCEPT

        fi

    done

fi

The problem with this approach is that it does not integrate with other functions of ClearOS like OpenVPN. OpenVPN can be got round by adding the subnets to EXTRALANS in /etc/clearos/network.conf. I have no idea what other side effects there are.

As an alternative, you can just create a firewall script to cut communication between the LAN's. It would have to insert rules rather than append them and wit would be better if it ran as an 05- type rule, so before all the 10-rules. I'll have a think about that.

grep line changed again so as to not touch port forwards or 1-to-1 NAT.

Minor amendment to script (remove "\-\- " from the grep command)

Note this script will kill any port forwarding to a HotLAN

I have the firewall rules working. Create a file /etc/clearos/firewall.d/05-hotlans and in it put:

#!/bin/bash



# Source networking configuration.

. /etc/clearos/network.conf



# Bail if not ipv4

if [ "$FW_PROTO" != 'ipv4' ]; then

    return 0

fi



if [ -n "$HOTIF" ]; then



    # Clear all HotLAN rules

    for HotLAN in $HOTIF; do

        RULE_IDS=$($IPTABLES -nv --line-numbers -L FORWARD |\

            grep " $HotLAN *0\.0\.0\.0\/0 *0\.0\.0\.0\/0" | awk '{ print $1 }' | sort -rn)

        if [ -n "$RULE_IDS" ]; then

            for rule_id in $RULE_IDS; do

                $IPTABLES -D FORWARD ${rule_id}

            done

	    fi

    done

	

    # Add replacement HotLAN rules

    for HotLAN in $HOTIF; do

        if [ -n "$EXTIF" ]; then

            for WANIF in $EXTIF; do

                $IPTABLES -A FORWARD -i $HotLAN -o $WANIF -j ACCEPT

            done

	    fi

    done

fi

The restart your firewall.

The problem I am having is that, playing around in a VM, if I try to set both the true LAN interface and VLAN interface to be HotLAN, then there is in error in the Webconfig and /etc/sysconfig/network-scripts/ifup-eth gives "Device enp0s9.100 does not seem to be present, delaying initialisation.". That only happens when I have both enp9s0 and enp9s0.100 set to HotLAN. I think that is because you cannot have a VLAN without a proper LAN interface. It may be different for you in a real environment.

The only other thing you can do is add a bunch of Custom firewall rules to block the traffic you want.

Welcome to the forums. As a new poster, your first couple of posts get moderated so don't appear immediately. I have deleted your other post.

In an ideal world, setting a LAN interface as a HotLAN means it cannot communicate with other LAN's but other LAN's can communicate with it, so you should set all your LANs as HotLAN's, so the answer should be to set all your LAN's as HotLAN's. Unfortunately, the way the rules have been written, they only really work with a single HotLAN - see bug #22711.

This has come up a couple of times recently, and it should be fairly easy to script, deleting all HotLAN rules and replacing them with a new set. I may give it a go next week.