Reaching destinations via another (more privileged) VLAN

louis2

I have a computer in VLAN-A which should have a higher privileges than other computers in that VLAN. For that reason I would like to forwarded some traffic coming from that computer to VLAN-B (managment vlan), from where more action are allowed. Note that certain destinations in e.g. VLAN-C can only be reached from VLAN-B (VLAN-C is protected by floating rules)

Resume, where the privileged computer in VLAN-A should be capable to reach certain destinations / destination ports, the other computers in that vlan should not

What I tried is:

defining a VIP in VLAN-B
translating the VIP-address into the-real destination-address (using NAT)
access the destination from VLAN-A by using the VIP-address in VLAN-B

With the firewall partly opened, the destination is reached, but not the intended way.

the VIP address in translated to the destination address (as intended)
and the result is pushed back in VLAN-A (exactly the apposite from what I tried to archive)
and all other devices on VLAN-A can perform the actions intended to be exclusive to the privileged computer
(due to all kind of extra unwanted NAT rules are created in VLAN-A)

So the effective result of this Idea is zero
And the idea to reach the intended effect with less rules .....

Any one an idea how to reach the intended effect (on network / firewall level)?

Bob.Dig

@louis2 said in Reaching destinations via another (more privileged) VLAN:

Any one an idea how to reach the intended effect (on network / firewall level)?

You missing some fundamentals here... if a host on VLAN-A should be allowed to do more then allow it by creating rules only for this host, on VLAN-A.

louis2

@Bob-Dig

Yep, I did that, but that are a lot of rules !!

a couple of destinations (x)
a couple of ports per destination (y)
=> leads to significant no of rules (XxY)

And not only in VLAN-A but also some added floating rules to restrict incoming traffic (out rules)

So I what thinking, how to clean up all those rules a bit and then the Idea was born to route the traffic via the Managment-VLAN using a trick witk VIP's

As indicated, up to now the trick did not work as intended

Bob.Dig

@louis2 There is a copy dialog for rules, although I wish it would allow to copy to/from floating too.

louis2

@Bob-Dig
I know you can copy rules and that there are strange things / limitations just as example, you can only disable nat-rules from within the edit menu. Why ???

But that does not solve my with to make things less complicated. There are three things here:

defining the rules
maintaining the rules
and performance

less rules = better performance;
less conditions per port => less real rules = better performance
the higher the rule, the less rules needs to be processed = better performance
rules which need highest performance in floating

So I still scratching my head

heper

@louis2
are you sure you aren't overcomplicating things ?

it would be helpful if you would explain in detail what the intended outcome is ...

@louis2 said in Reaching destinations via another (more privileged) VLAN:

a couple of destinations (x)
a couple of ports per destination (y)
=> leads to significant no of rules (XxY)

this is can mean just about anything

louis2

@heper

As example assume:

20 systems to manage
4 each https, ssh and two other ports
1 only allow ipv4 for management
2 vlans where the pc can be connected to

20 x 2 = 40 rules on pfSense level
20 x 4 x 1 x 2 = 160 rules on pf level

Since performance is not an issue for management, and I do not have a better option,
I am moving management related rules to the end of the vlan-rule-sets now

like this
--- for every one ---

x normal rules
--- for privileged systems only ---
1 block rule for every system not privileged
1 block rule for ports not management ports
n simple pass rules towards systems to manage
--- end of rules ---

However this could imply that I have to make normal rules "more strict"
Reorganizing rules now, considering what works best

heper

@louis2

I don't understand why you would want seperate rules for all 'clients' because By default everything is blocked.

Why not create a couple of aliases?

priv_src_devices (IP addresses or subnets)
priv_dst_services (ports)
priv_dst_devices (IP adresses or subnets)

Then you could just add 1 rule on top like

SRC: priv_src_devices
DST: priv_dst_devices
Ports: priv_dst_services

louis2

@heper

You are partly right, but it is far more complex

all thing starting on a (v)lan is default blocked
and Yep I am using lots of aliases

And ... beware that ^the rules for all clients^ are also for "all privileged clients". I just define additional pass rules for them.

However be aware that aliases are simplifying to define rules, but do lead to many rules under the hood.
example: allow ipv4+ipv6 from alias:dest1&dest2 for ports a,b,c => 2x2x3=12 pf rules
That is especially relevant in case performance is an issue. That aside.

Rules are of course processed in the order they are listed. That processing order does imply, that you can not put rules in an random order.
From the security standpoint a rule list should begin with things which are not allowed, starting with the most specific rules etc.
Placing a more global rule in front of a more specific one would imply that the second rule will never be reached

As written above at this moment I have one rule list with contains both rules for every system and for privileged systems. That works, I am just not happy with that solution
So I am thinking about / considering alternatives.

heper

@louis2
@louis2 said in Reaching destinations via another (more privileged) VLAN:

However be aware that aliases are simplifying to define rules, but do lead to many rules under the hood.
example: allow ipv4+ipv6 from alias:dest1&dest2 for ports a,b,c => 2x2x3=12 pf rules

no that is not the case. see example below

the GUI rule above consists of these aliases

# User Aliases 
table <testdst> {   10.49.24.1  10.49.24.2  10.49.24.3  10.49.24.4 } 
testdst = "<testdst>"
testports = "{   120  121  122  123 }"
table <testsrc> {   10.49.23.1  10.49.23.2  10.49.23.3  10.49.23.4 } 
testsrc = "<testsrc>"

and generates exactly 2 pf rules (1 for ipv4 / 1 for ipv6)

pass  in  quick  on $LAN inet proto { tcp udp }  from $testsrc to $testdst port $testports ridentifier 1706119469 keep state  label "USER_RULE: testrule_forum"
pass  in  quick  on $LAN inet6 proto { tcp udp }  from $testsrc to $testdst port $testports ridentifier 1706119469 keep state  label "USER_RULE: testrule_forum"

@louis2 said in Reaching destinations via another (more privileged) VLAN:

Rules are of course processed in the order they are listed. That processing order does imply, that you can not put rules in an random order.

correct
@louis2 said in Reaching destinations via another (more privileged) VLAN:

From the security standpoint a rule list should begin with things which are not allowed, starting with the most specific rules etc.

from a security standpoint it doesn't matter if your list begins with blocks or allows. you want to achieve x. it doesn't matter how you get there in the end

@louis2 said in Reaching destinations via another (more privileged) VLAN:

Placing a more global rule in front of a more specific one would imply that the second rule will never be reached

correct

if you could post some screenshots of your rules,interfaces,network diagram, ... then maybe someone can help to simplify the setup.

@louis2 said in Reaching destinations via another (more privileged) VLAN:

As written above at this moment I have one rule list with contains both rules for every system and for privileged systems. That works, I am just not happy with that solution

nobody would be happy to have a zillion rules

louis2

@heper

Strictly seen you are right if you say that the rule order is less strict than I did suggest. If there are reasons to choose another rule order (e.g. performance), I use (partly) another order myself.

Related to the difference in ^pfSence-rules^ and ^pf-rules^ at this moment I can only say that "pfctl -vvsr" shows that ^pfsense-rules^ are expanded to a lot more rules. Perhaps it is not as bad as I suggested in my example. No time to investigate that now.

What ever, I am not there in the next few days.
So I will scratch my head after that break.