Accesslist

[Wizard]

I create 2 Hubs, 1 "LANBridge", bridged to LAN-NIC, another "VPN". VPN uses secureNAT for DHCP only. l3 router in between for routing between VPN-subnet 10.240.0.254/24 and LAN 192.168.0.254/24.
On VPN-Hub, I create several users and groups, eg. a GroupA and a GroupB.
I now want to give everyone NO access whatsoever, so I create an access rule "DenyAll" without group/user filled in, prio 99999 and on the right All IPv4/IPv6.
Action is Deny.
Hmmm... That's too much, now DHCP inside the VPN don't work, so I change the rule Destination 192.168.0.0/255.255.255.0. That works eg. nothing works from inside the VPN as that's what I wanted.
Now I want to enable some stuff depending on group. So I create a new rule "Allow Server", source group = GroupA, Destination address 192.168.0.1/255.255.255.255, All IPv4, action = pass
This now doesn't work. After alot of trial and error, if I add the GroupA to the DenyAll rule also, it works.
Question: Is it required to use the same GroupA for both the allow and deny rules to make it work this way ?
Or generally, how to deny everything execpt what's necessary to connect (DHCP that is). What would that generic deny rule look like.
Or rephrased question: If you don't fill in a group/user, does that mean like any traffic from any user connected to that hub ? or does it mean "ONLY traffic that doesn't include a user" ?
Difference ofcourse is: I'd wanted to have one generic DenyAll rule, then just add pass-rules for each group before it, but with more than 1 group, this seems to mean I also need to add multiple deny-rules per group ?

[solo]

If you don't fill in a group/user, does that mean like any traffic from any user connected to that hub ?

Yes. The rest is explained here:
"add a reversal route for returning packet" https://www.vpnusers.com/viewtopic.php?t=5576#p55486
VPN Gate rules https://www.vpnusers.com/viewtopic.php? ... 039#p97841
[L3 site-to-site one-way] https://www.vpnusers.com/viewtopic.php?f=7&t=68988

[Wizard]

I checked those but I don't (completely) understand them. I want to block everything, not just ie. TCP or some ports or the usual SMB etc.
This setup is split tunnel, so I already only get routed a few IPs from the entire subnet inside the tunnel to the servers and back (setup dhcp option 121 with routes only for those servers I want through the tunnel)...
I get I am using the L3 routing in between, but fail to see what that has to do with it, as all traffic I want to block coming in or out of this hub only, what happens on the other side of the L3 (LAN-side of servers) I don't bother. It starts this side on this hub I try to create the rules.
If I would need to add return traffic rule, does that mean and imply then that these rules don't have any logic in them, meaning, they are not and do not honor "statefulness" ? I mean, if you allow a source IP x to a dest IP y port z on a firewall, the fireall "auto"-creates an invisible return traffic rule to allow the return traffic from dst IP y port z back to the src IP... These rules you create here are not like that ? So in the case here with routing you need 2 rules to allow something back and forth, if you have a global denyall rule on the bottom ?

Is there documentation somewhere explaining these settings in detail, like the established/unestablished, etc. ?
Also, I tried the logging, ramping that up to see if anything gets logged (like getting blocked, only logging one way, etc.) but am I correct in saying, it only gets logged when it succeeds in passing through ? In other words, anything getting blocked never gets logged, or is there a way somehow to reveal what gets blocked while creating and tuning these rules ?

[solo]

The access list is stateless. Here is an easily manageable and highly scaleable template applicable in your context:

Code: Select all

1 Action: Pass, Status: Enable, Priority: 1000, Memo: DHCP, Contents: (ipv4) Protocol=UDP, SrcPort=67-68
2 Action: Pass, Status: Enable, Priority: 1100, Memo: DHCP, Contents: (ipv4) Protocol=UDP, DstPort=67-68
3 Action: Pass, Status: Enable, Priority: 1200, Memo: group1, Contents: (ipv4) DstIPv4=192.168.0.1/32, SrcUser=group1
4 Action: Pass, Status: Enable, Priority: 1300, Memo: group3, Contents: (ipv4) DstIPv4=192.168.0.3/32, SrcUser=group3
5 Action: Pass, Status: Enable, Priority: 1400, Memo: return, Contents: (ipv4) SrcIPv4=192.168.0.0/255.255.255.250
6 Action: Discard, Status: Enable, Priority: 1500, Memo: all, Contents: (ether) *

On my bridged VPN servers are in low IP range and clients on high IPs. On your L3-etc. simply set #5 as:

Code: Select all

5 Action: Pass, Status: Enable, Priority: 1400, Memo: return, Contents: (ipv4) SrcIPv4=192.168.0.0/32

[Wizard]

Well, unfortunately can't get it to work...

LAN = 192.168.0.0/24 bridged to Hub LANBridge
VPN = 10.240.240.0/20 bridged to Hub VPN

Name of Virtual Layer 3 Switch: L3
IP Address |Subnet Mask |Virtual Hub Name
--------------+-------------+----------------
192.168.0.40 |255.255.255.0|LANBridge
10.240.255.254|255.255.240.0|VPN

AccessList command - Get Access List Rule List
Item |Value
---------+----------------------------------------------------
ID |1
Action |Pass
Status |Enable
Priority |1
Unique ID|19560594
Contents |(ipv4) Protocol=UDP, SrcPort=67-68
Memo |DHCP
---------+----------------------------------------------------
ID |2
Action |Pass
Status |Enable
Priority |2
Unique ID|1503392552
Contents |(ipv4) Protocol=UDP, DstPort=67-68
Memo |DHCP
---------+----------------------------------------------------
ID |3
Action |Pass
Status |Enable
Priority |1000
Unique ID|2123469668
Contents |(ipv4) DstIPv4=192.168.0.253/32, SrcUser=Full Access
Memo |FullAccess
---------+----------------------------------------------------
ID |4
Action |Pass
Status |Enable
Priority |999991
Unique ID|1242684548
Contents |(ipv4) SrcIPv4=192.168.0.0/24
Memo |Return
---------+----------------------------------------------------
ID |5
Action |Discard
Status |Enable
Priority |999999
Unique ID|2308134863
Contents |(ether) *
Memo |DenyAll

This doesn't do the trick. When I remove SrcUser=Full Access (Group Name) then it works...
In other words, as far as I can understand things rule 3 doesn't match when Group or User is added, but does get hit without it.
Doublechecked that it is rule 3 getting hit by changing IP 192.168.0.253 to 192.168.0.120 (just another server which should work) and that too does NOT work with User/Group but does work without User/Group ???


But, as you can see here, I really am user bart or Bart from Group "Full Access", IP DHCP gave me for this session is 10.240.240.1

SessionGet command - Get Session Information
Item |Value
------------------------------------------+---------------------------------------------------------------
Client IP Address |??.??.??.??
Client Host Name |something
User Name (Authentication) |bart
User Name (Database) |Bart
Group Name |Full Access
VLAN ID |-
Server Product Name |SoftEther VPN Server (64 bit)
Server Version |4.43
Server Build |Build 9799
Connection Started at |2024-07-18 (Thu) 21:36:37
First Session has been Established since |2024-07-18 (Thu) 21:36:37
Current Session has been Established since|2024-07-18 (Thu) 21:36:37
Half Duplex TCP Connection Mode |No (Full Duplex Mode)
VoIP / QoS Function |Enabled
Number of TCP Connections |8
Maximum Number of TCP Connections |8
Encryption |Enabled (Algorithm: TLS_AES_256_GCM_SHA384)
Use of Compression |No (No Compression)
Physical Underlay Protocol |Standard TCP/IP (IPv4)
|IPv4 UDPAccel_Ver=2 ChachaPoly_OpenSSL UDPAccel_MSS=1309
UDP Acceleration is Supported |Yes
UDP Acceleration is Active |No
Session Name |SID-BART-10
Connection Name |CID-99
Session Key (160 bit) |4FBC69FF6E07C31363B90AA0382D2A57CEE9ACFB
Bridge / Router Mode |No
Monitoring Mode |No
Outgoing Data Size |2,753,134 bytes
Incoming Data Size |2,646,041 bytes
Outgoing Unicast Packets |2,185 packets
Outgoing Unicast Total Size |131,506 bytes
Outgoing Broadcast Packets |486 packets
Outgoing Broadcast Total Size |37,555 bytes
Incoming Unicast Packets |1,252 packets
Incoming Unicast Total Size |72,412 bytes
Incoming Broadcast Packets |380 packets
Incoming Broadcast Total Size |17,388 bytes
Client Product Name (Reported) |SoftEther VPN Client
Client Version (Reported) |4.43
Client Build (Reported) |Build 9799
Client OS Name (Reported) |Windows 11
Client OS Version (Reported) |Build 22631, Multiprocessor Free (22621.ni_release.220506-1250)
Client OS Product ID (Reported) |--
Client Host Name (Reported) |HOME
Client IP Address (Reported) |???.???.???.???
Client Port (Reported) |55136
Server Host Name (Reported) |???.???.???.???
Server IP Address (Reported) |???.???.???.???
Server Port (Reported) |443



None of the logs mention User/Group, only which session it came from...
If I set User on rule 3 it stops working, in the log I then see SYN-packets going to the localbridge, nothing comes back. Removing the group, still see sync packets going to localbridge, but also see the ACK packets coming back. Rule 3 is supposed to act on incoming traffic from VPN, coming from this session. User/Group is derived from this session-ID ? Then it still makes no sense as changing user or no user still makes the packets go to localbridge, it just changes if something comes back or not...
So adding a user/group makes the return traffic not work any longer ?!?!?!
It would be a huge help if the logging included the ID of the accesslist rule (if any) that was checked and found to apply !!!
The logs just don't show where this exactly now is going wrong, making troubleshooting this a nightmare.

[Wizard]

Solo, I think this doesn't work because I'm testing this on a cluster of 3 servers ?
2 members, 1 controller, controller has the L3...
So, while my incoming traffic on VPN1 passes the accesslist there with group, traffic then bridges to the controller on the VPN bridge, goes to the L3, and gets blocked, as now the traffic is from L3, not user Bart anymore...
In other words, can it be the traffic loses it's user/group identity when clustered while there's only one L3 in a cluster...
This also explains why, if you add user/group to the deny, it also works, as then the Deny rule on the controller with the L3 simply doesn't apply and passes on back to VPN1 which passes it back to the VPN-client...

eg, log from controller which has the L3, while I try to connect 192.168.0.120:3389 from 10.240.240.1
Note the Identity SID-Bart-10 is gone here, because my session lives on server VPN01, so accesslist works on that hub, but accesslist rule 3 doesn't apply here on this controller for the L3...?

2024-07-18,22:50:04.980,SID-LOCALBRIDGE-VPNCONTROLLER-1,SID-L3-VPNCONTROLLER-L3-3,5E8FA07E4AD7,5EA3F480C3F0,0x0800,54,TCP_CONNECTv4,FIN+ACK,10.240.240.1,59715,192.168.0.120,ms-wbt-server(3389),3852660365,2536898655,WindowSize=64240,-,-,-
2024-07-18,22:50:04.980,SID-L3-VPNCONTROLLER-L3-3,SID-LOCALBRIDGE-VPNCONTROLLER-1,5EA3F480C3F0,5E8FA07E4AD7,0x0800,54,TCP_DATAv4,ACK,192.168.0.120,ms-wbt-server(3389),10.240.240.1,59715,2536898655,3852660366,WindowSize=64000,-,-,-

2 questions then:
1) In a cluster, as you work with only one Hub which gets "replicated" on members, the same applies to the Accesslist on that Hub ? Gets replicated aswell ?
2) Is this still possible somehow or are user/group based accesslists then simply not possible/working in a clustered setup where you also do L3 between 2 Hubs ?

[solo]

There is an alternative method based on Access List Source IP Address. You'd need to replace the vDHCP with a full-featured DHCP server and let it assign static IPs.

[Wizard]

For this cluster I'm having dedicated MS-DHCP on both cluster-members. They are doing DHCP failover to 'sync'... Works perfectly by the way :-)
They are bound to the NIC, bridged with the VPN-HUB, providing IPs for clients. I've examined the "fixed-ip" DHCP setup, but that's unworkable for what we want to achieve with this setup.
The issue here I think is the L3 'abstracting' the user/group identity from the traffic. You got to keep in mind any accesslist rule you create is running on all 3 servers (I assume based on the fact each HUB you create is running on all 3 aswell). So using a 'denyall" WITH a user/group works for that group. It then just means you have to make very sure that you "address" every group you want on that HUB, with a set of allow/deny rules. That way, the rule you create "works" on the "source" where you're client is coming from (member 1 or 2 in this case), but your same rule is not hitting anything on the controller which has the L3, and thus not blocking any (same of your) traffic passing there through the L3. In this case, that's exactly what you'd want, thus creating a rule-set that only pertains to the "source". Ofcourse then though, this is NOT a real DenyAll since it's only a deny for that group.
You then HAVE to make VERY sure you create a set of rules like this for EVERY group to make sure everyone gets denied in doing what's not allowed. All those deny-rules together then have the same effect of 1 general deny-rule for the whole setup.

So I've got a workaround for a setup like this, but it does make things tricky and complicated to say the least...