Kein rdp-Zugriff auf Firmennetz mit SSL-VPN

Options
WGLAN
WGLAN Posts: 6
First Anniversary Friend Collector First Comment

Hallo,
der Aufbau einer SSL-VPN mit dem SecuExtender von meinem Win10-PC zu einem Firmennetz über eine USG40W klappt ohne Probleme. Siehe Abb. 1. und Abb. 2
Der Win10-PC bekommt de IP 192.168.100.10 zugewiesen. (siehe auch Abb. 3)
Aber ich bekomme keinen rdp-Zugriff auf den Arbeitsplatz 192.168.100.140 oder 1xx im Firmen-LAN. In der Firewall (Policy control) ist für den Verkehr from SSL-VPN to LAN1 und in die Gegenrichtung alles freigeschaltet. Die Firewall an den PC-Endpunkten habe ich testweise deaktiviert. Ein PING wird auch nicht beantwortet.

Woran kann es liegen? Für jeden Hinweis bis ich dankbar.

Gerhard

Best Answers

  • USG_User
    USG_User Posts: 369  Master Member
    First Anniversary 10 Comments Friend Collector First Answer
    Answer ✓
    Options

    Hi Gerhard,

    At the first glance it looks similar to mine, including the same Security Policy rules from WAN to ZyWall, from SSLVPN to LAN1 and from LAN1 to SSLVPN.

    Only one difference … we are not using IPs from the LAN1 subnet also for the SSLVPN clients. For example, our LAN1 subnet is 192.168.21.x and we assign IPs from 192.168.121.x to connecting VPN clients. Don't ask me why, long time ago that this was discussed here.

    Further there is a SSLVPN Global Setting where a Network Extension Local IP has to be defined. This is set to 192.168.200.1. This was factory default and has never be changed.

    Finally please check also Maintenance > Diagnostics > System Log for more detailed information on dropped packages. Hopefully you got an USB stick connected to your USG for collecting more detailed logs.

  • WGLAN
    WGLAN Posts: 6
    First Anniversary Friend Collector First Comment
    Answer ✓
    Options

    Hi,

    thank you Jeff and USG-User. I was able to test your suggestions today. The hint from USG-User made the rdp work over the SSL-VPN. I did not have to modify our security policies, just define a different IP range.

    Thanks again for your support.

    Gerhard

All Replies

  • Zyxel_Jeff
    Zyxel_Jeff Posts: 1,083  Zyxel Employee
    First Anniversary 10 Comments Friend Collector First Answer
    Options

    Hi @WGLAN

    Thanks for your inquiry. When you cannot ping the internal client (192.168.100.140) from your SSL VPN Client(192.168.100.10), please check whether there is any blocked or dropped message on the Monitor Log to see the possible reason. Maybe it is blocked by another security policy. Secondly, yo can capture the packet on the internal client (192.168.100.140) to see whether can receive the ping traffic from the SSL VPN client(192.168.100.10). Thanks.

  • WGLAN
    WGLAN Posts: 6
    First Anniversary Friend Collector First Comment
    Options

    Hi Jeff

    Thank you for your recommendation. I will check it.

    Regards, Gerhard

  • USG_User
    USG_User Posts: 369  Master Member
    First Anniversary 10 Comments Friend Collector First Answer
    Options

    Moin Gerhard,

    Properly adjusted, there are no problems with RDP over SSL-VPN. In past we used it on an USG110, and this time over an USG Flex 700. If you are not able to solve the problem, taking into account Jeff's hints, please let us know and we go through our config step by step.

    Gruss aus Rostock

  • WGLAN
    WGLAN Posts: 6
    First Anniversary Friend Collector First Comment
    edited August 2023
    Options

    Good Morning,

    On the weekend I finally could repeat the test and capture the Monitor Log as Jeff had suggested. The Monitor log from the test is appended.

    Entries 19 to 15 show the establishment of the tunnel

    Entries 13, 11, 10, 8, 6 show dropped packets during rdp-connection

    Entries 5 to 1 show, when we disconnected the tunnel from the Client side.

    I have two questions. Hopefully somebody can clarify them to solve our problem.

    • The entries for the tunnel establishment show 192.168.172.2 as the destination which is the WAN interface on the USG40 towards the DSL-Modem. Why that?
    • During the rdp-connection establichment packets from our client on port 137 and 138 are dropped. Why? I attach the security policies which are quite open. I expected, that #5 and #12 should let these packets pass. Which security policy is missing? These blocked messages seem to cause our problem to me.

    Thank you in advance for any ideas how to resolve the issue.

    Regards,

    Gerhard

  • USG_User
    USG_User Posts: 369  Master Member
    First Anniversary 10 Comments Friend Collector First Answer
    Answer ✓
    Options

    Hi Gerhard,

    At the first glance it looks similar to mine, including the same Security Policy rules from WAN to ZyWall, from SSLVPN to LAN1 and from LAN1 to SSLVPN.

    Only one difference … we are not using IPs from the LAN1 subnet also for the SSLVPN clients. For example, our LAN1 subnet is 192.168.21.x and we assign IPs from 192.168.121.x to connecting VPN clients. Don't ask me why, long time ago that this was discussed here.

    Further there is a SSLVPN Global Setting where a Network Extension Local IP has to be defined. This is set to 192.168.200.1. This was factory default and has never be changed.

    Finally please check also Maintenance > Diagnostics > System Log for more detailed information on dropped packages. Hopefully you got an USB stick connected to your USG for collecting more detailed logs.

  • Zyxel_Jeff
    Zyxel_Jeff Posts: 1,083  Zyxel Employee
    First Anniversary 10 Comments Friend Collector First Answer
    Options

    Hi @WGLAN

    The main issue could be related to the security policy "SSL_VPN_Outgoing." You can modify your current configuration to match the default security policies for "SSL_VPN_Outgoing" and "SSL_VPN_to_Device." This will allow you to utilize the SSL VPN client for accessing LAN1 and the firewall device.

    Thanks.

  • WGLAN
    WGLAN Posts: 6
    First Anniversary Friend Collector First Comment
    Answer ✓
    Options

    Hi,

    thank you Jeff and USG-User. I was able to test your suggestions today. The hint from USG-User made the rdp work over the SSL-VPN. I did not have to modify our security policies, just define a different IP range.

    Thanks again for your support.

    Gerhard

Security Highlight