VPN Manage Access List?

[sdevries.otn]

1. Operating system name and the type of CPU-bits:
CentOS 6.5 x64

4. The build number of SoftEther VPN:
4.08 build 9449

5. Which SoftEther VPN component are you using?
Server, Server Manager Gui (through WINE).

6. Whether or not there is a NAT or Firewall between your VPN server and the Internet.
Yes, ERlite3 router/NAT, setup to forward all standard listener ports to the VPN Server. (Works great.)

7. Are you using SecureNAT?
No

What I would like to do is limit a specific user(s), to only RDP protocol, to a specific IP address on the local LAN. It seems like this is possible, I am just not quite sure what I need to input.

Action: Pass
Source Name: <User Name>
Destination IP: 192.168.0.2 (local LAN IP address of PC that is being RDP'ed into.)
Subnet Mask: 255.255.255.255
Protocol Type: 6
Port # SRC: 3389 / 3389
Port # Dest: 3389 / 3389

[A duplicate rule of the above, except for UDP protocol.]

Final rule drops all packets from <User Name>, for 192.168.0.0, 255.255.255.0. [The entire subnet.]

I can get an IP just fine, but I cannot RDP at all. Says the computer cannot be found. Are there more ports I need to open?

[dajhorn]

> Port # SRC: 3389 / 3389

This could be the problem. Don't restrict traffic by source port.

Start with a simple rule that restricts only by username, and then add parts until the rule breaks the remote desktop connection.


> I can get an IP just fine, but I cannot RDP at all. Says the computer cannot be found. Are there more ports I need to open?

Also try connecting by IP address. These rules will break anything that depends on autodiscovery, broadcasts, or name resolution.

[sdevries.otn]

I had thought about the last filter blocking access the DNS just before leaving last night. Didn't have a chance to test until this morning.

I removed the source ports from both the TCP/UDP as suggested. This allows it to work while the block everything rule is in place. As long as I use IP address it works well.

If I use a PC name, it takes much longer (~1 min vs. ~2 seconds) to secure connection / login. Once you are in, it seems to run acceptably though. I assume, this is a DNS issue, since we are blocking all the traffic to anything on the LAN.

DNS queries are sent from (>= 49152) to 53. Responses are from 53 to (>= 49152), via TCP or UDP depending on message type.

EDIT:
Rule 1: Source Name=<Group>, Destination IP <Server IP>, Destination Port: 53, UDP
Rule 2: Source Name=<Group>, Destination IP <Server IP>, Destination Port: 53*, TCP
Rule 3: Destination name = <Group>, Source IP <Server IP>, TCP
Rule 4: Destination name = <Group>, Source IP <Server IP>, UDP
Rule 5: Source Name=<Group>, Destination Port 3389, TCP
Rule 6:Source Name=<Group>, Destination Port 3389, UDP
Rule 7: DISCARD Source Name=<Group>, apply to any IP source and Destination, apply to any protocol/port.*

EDIT: 2
* I changed this from X.X.X.0 / 255.255.255.0 to simply checking the check box. So this rule would now deny all traffic from <group> from any source IP to any destination IP via any protocol using any port #. Now using 53 in rule 2 works. Prior, it would fail.

Now I have one last weird behavior to solve. When changing rule 7 my VPN client IP address changed! It can no longer connect to our DHCP server (I supposed that should be expected, given what the rule does).

It was getting an old lease for our AD/DNS server (which currently has its DHCP disabled). Release/Renew causes me to connect to the default " I cannot find a DHCP server" IP. Makes sense if I cannot connect to the new DHCP server.

Is there a way in SoftEtherVPN server manager to verify where it is pointing for DHCP?
I think to either reset where the VPN server is trying to get IP's from, or add another rule to the group to able to connect to the DHCP server.

[sdevries.otn]

I fixed the DHCP issues completely by release/renew on the client, and some rules to open the ports. Now I have the same issue with putting TCP port 53 in a rule though. It kills DNS.

(Allow DHCP) [Working Great]
Rule 1: Source Name=<Group>, Destination Port: 67, UDP
Rule 2: Source Name=<Group>, Destination Port: 68, UDP

(Allow DNS)
Rule 3: Source Name=<Group>, Destination IP <DNS Server IP>, Destination Port: 53, UDP
Rule 4: Source Name=<Group>, Destination IP <DNS Server IP>, Destination Port: *53*, TCP
Rule 5: Destination name = <Group>, Source IP <DNS Server IP>, TCP
Rule 6: Destination name = <Group>, Source IP <DNS Server IP>, UDP

(Allow RDP) [Working Great]
Rule 7: Source Name=<Group>, Destination Port 3389, TCP
Rule 8:Source Name=<Group>, Destination Port 3389, UDP

(Block Everything Else) [Working Great... maybe a little too well.]
Rule 9: DISCARD Source Name=<Group>, apply to any IP source and Destination, apply to any protocol/port.

I am back where I was earlier this morning. I just can't seem to figure out rule # 4 above. To my understanding, a DNS server should listen for ports 53 on both UDP and TCP. So why is filtering packets from <group> to <server IP address> using TCP to port 53 breaking DNS. But leaving it blank (any port #) works perfectly fine? I am really stumped on this one.

EDIT: fixed a typo and added some clarification details.

[sdevries.otn]

Well... it turned out to be port 88... Kerberos, for the RDP authentication. *facepalm*.