Openvpn drops while establish rdc



  • Hi,
    Through PfSense Openvpn client, I am able to establish the connection & able to ping all nodes on that network. But huge packet loss will occur when I tried to initiate an rdc session & eventually I cant access any of the services on destination rather than ICMP. where can I see the root cause

    regards
    sreyas


  • LAYER 8 Rebel Alliance

    RDC = RDP?
    I work all day long with RDP via OpenVPN/pfSense with no problem.
    Describe your Setup, show Settings and Log. ATM we know nothing about your equipment, not even which version of pfSense or Hardware you're on.

    -Rico



  • Same here.
    I activated the OpenVPN server on pfSense to "RDP" to my servers and pfSense maintenance.
    Works well, for hours if needed.

    @sreyas It's time to detail your setup. Plesae include the screen where we can find the issue ;)



  • @gertjan in fact i can't find any relevant information from logs, could you please let me know what exact info are you looking for. Whether its a firewall log / vpn log.

    1. VPN packet lose is happening only for some specific providers [ISP]
    2. I can't identify where & what is this issue [ovpn log is clear ]
    3. firewall log shows there is a block, i had passed one easy rule - but no issue.

    Regards
    Sreyas



  • In that case, it could be a simple bandwith issue.
    A speedtest through a VPN tunnel doesn't reveal anything ? Do the test and ping also through the tunnel at the same time.



  • @gertjan I had done this, as I said bandwidth is pretty stable. here is how it goes

    1. VPN Connection established - without any issues
    2. able to ping any local resource through VPN without any packet loss
    3. moment when we try to establish an rdp / vnc session packet loss will occur
    4. Cant find any trace in vpn logs
    5. firewall sometime shows traffic is blocked with some random ports - but not always

    Regards
    Sreyas



  • @sreyas please find the below logs from server side & client

    Client Side

    Mon Dec 31 13:54:52 2018 DEPRECATED OPTION: --tls-remote, please update your configuration
    Mon Dec 31 13:54:52 2018 OpenVPN 2.3.18 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Sep 26 2017
    Mon Dec 31 13:54:52 2018 Windows version 6.2 (Windows 8 or greater) 64bit
    Mon Dec 31 13:54:52 2018 library versions: OpenSSL 1.0.2l 25 May 2017, LZO 2.10
    Mon Dec 31 13:54:58 2018 Control Channel Authentication: using '----tls.key' as a OpenVPN static key file
    Mon Dec 31 13:54:58 2018 UDPv4 link local (bound): [undef]
    Mon Dec 31 13:54:58 2018 UDPv4 link remote: [AF_INET]---------:1194
    Mon Dec 31 13:54:58 2018 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
    Mon Dec 31 13:55:02 2018 [openvpn] Peer Connection Initiated with [AF_INET]---------------:1194
    Mon Dec 31 13:55:05 2018 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
    Mon Dec 31 13:55:05 2018 open_tun, tt->ipv6=0
    Mon Dec 31 13:55:05 2018 TAP-WIN32 device [Ethernet 2] opened: \.\Global{13DA7F48-0F8D-4DEB-B549-7DD7646C4E7D}.tap
    Mon Dec 31 13:55:05 2018 Set TAP-Windows TUN subnet mode network/local/netmask = 10.70.0.0/10.70.0.12/255.255.0.0 [SUCCEEDED]
    Mon Dec 31 13:55:05 2018 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.70.0.12/255.255.0.0 on interface {13DA7F48-0F8D-4DEB-B549-7DD7646C4E7D} [DHCP-serv: 10.70.255.254, lease-time: 31536000]
    Mon Dec 31 13:55:05 2018 Successful ARP Flush on interface [5] {13DA7F48-0F8D-4DEB-B549-7DD7646C4E7D}
    Mon Dec 31 13:55:10 2018 Initialization Sequence Completed

    Server Side

    Dec 31 13:55:02 openvpn 4002 admin/-----------------------:5871 MULTI_sva: pool returned IPv4=10.70.0.12, IPv6=(Not enabled)
    Dec 31 13:55:01 openvpn user 'admin' authenticated
    Dec 31 13:55:01 openvpn 4002 -----------------------:5871 [admin] Peer Connection Initiated with [AF_INET]-----------------------:5871
    Dec 31 13:55:01 openvpn 4002 -----------------------:5871 peer info: IV_GUI_VER=OpenVPN_GUI_10
    Dec 31 13:55:01 openvpn 4002 -----------------------:5871 peer info: IV_PROTO=2
    Dec 31 13:55:01 openvpn 4002 -----------------------:5871 peer info: IV_PLAT=win
    Dec 31 13:55:01 openvpn 4002 -----------------------:5871 peer info: IV_VER=2.3.18



  • Your logs confirm the tunnel creation.

    True, nothing will be shown about "how big" the tunnel is,or : what can be pushed through it.
    ping, as a low priority protocol, not making it anymore looks like a bandwidth issue. The fact that this happens only with some ISP could mean they are throttling OpenVPN traffic. Try changing the default 1194 port.
    Or it is OpenVPN that just can't push more information through the tunnel.

    Or some shaping issue - do you have shaping activated on pfSense ?

    Btw : lower the screen res of your RDP session : syncing a high res screen is a bandwidth eater.



  • You are absolutely right , this is only happening with some specific providers rest all are working fine without any issues.
    I know this is stupid, but is there any workaround / fix in order to overcome bandwidth throttling from ISP.
    I will change the default port & try - will let you know the status
    Traffic shaping is not activated on PfSense.