Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 2 subscribers
  • Views 1794 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

RDP and VNC default drop after 7.502 update.

Timid1
I have recently updated my 3 Astaro devices at my 3 locations to the 7.502 firmware update. Before, the Remote Desktop and Tight VNC connections would work perfectly across a VPN connection to wach location. After the update, 2 of the locations work perfectly, but the third is showing me default drops in the Live Log when I try to remote connect to the PC at that location. RDP still works within the local LAN, but I cannot Remote in through the VPN tunnel. I have copied the Packet Filter rules (with the correct IP addresses) from the other identical unit that is working, and applied them to the not functioning unit and still can't get the default drop issue to resolve. Does anyone have any suggestions, or is this a problem other people have had since the 7.502 update?


This thread was automatically locked due to age.
  • 0
    Hi, Timid1, and a belated "Welcome!" to the User BB.

    It always helps to show the relevant line(s) from the approriate log; indeed, that's my first question - please show the lines from the log (not the live log, as that is not as complete).

    Also, if you are accessing by name, have you tried by numeric IP?  Which site-to-site or remote access VPN?  Please show a pic of the appropriate page for 'Local networks' for a site that works and a site that doesn't.

    Cheers - Bob
  • 0
    I am connecting via a PPTP connection, and am using the numerical IP address through both RDP and Tight VNC. I am not specifying port number, but rather am letting the application go to the default ports of 3389 for RDP and 5900 for VNC. Below is the text from both the Packet Filter log as well as the "Live Log" for reference. Part of what bothers me is that I don't see either the 3389 or 5900 ports in either log, even though these log entries correspond directly to when I attempt a remote connection.


    Packet Filter Log Output

    2009:12:28-06:33:03 806 ulogd[3239]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" seq="0" initf="eth1" outitf="unknown" dstmac="00:1a:8c:10:xx:b3" srcmac="00:00:00:00:00:00" srcip="65.xx.xx.xx" dstip="69.xx.xx.xx" proto="6" length="40" tos="0x00" prec="0x00" ttl="241" srcport="80" dstport="55098" tcpflags="ACK RST" 

    2009:12:28-06:33:35 806 ulogd[3239]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" seq="0" initf="eth1" outitf="unknown" dstmac="00:1a:8c:10:xx:b3" srcmac="00:00:00:00:00:00" srcip="66.xx.xx.xx" dstip="69.xx.xx.xx" proto="6" length="40" tos="0x00" prec="0x00" ttl="244" srcport="80" dstport="46638" tcpflags="ACK RST" 

    2009:12:28-06:33:40 806 ulogd[3239]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" seq="0" initf="eth1" outitf="unknown" dstmac="00:1a:8c:10:xx:b3" srcmac="00:00:00:00:00:00" srcip="24.xx.xx.xx" dstip="69.xx.xx.xx" proto="17" length="284" tos="0x00" prec="0x00" ttl="63" srcport="500" dstport="500" 

    2009:12:28-06:34:20 806 ulogd[3239]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" seq="0" initf="eth1" outitf="unknown" dstmac="00:1a:8c:10:xx:b3" srcmac="00:00:00:00:00:00" srcip="24.xx.xx.xx" dstip="69.xx.xx.xx" proto="17" length="284" tos="0x00" prec="0x00" ttl="63" srcport="500" dstport="500" 

    Live Log Output

     
    len=284  ttl=63  tos=0x00  srcmac=00:00:00:00:00:00  dstmac=00:1a:8c:10:xx:b3
    06:39:40  Default DROP  UDP 
    24.xx.xx.xx  :  500
    → 
    69.xx.xx.xx  :  500

    len=284  ttl=63  tos=0x00  srcmac=00:00:00:00:00:00  dstmac=00:1a:8c:10:xx:b3
    06:40:20  Default DROP  UDP 
    24.xx.xx.xx  :  500
    → 
    69.xx.xx.xx  :  500

    len=284  ttl=63  tos=0x00  srcmac=00:00:00:00:00:00  dstmac=00:1a:8c:10:xx:b3
    06:40:30  Default DROP  UDP 
    24.xx.xx.xx  :  500
    → 
    69.xx.xx.xx :  500

    len=284  ttl=63  tos=0x00  srcmac=00:00:00:00:00:00  dstmac=00:1a:8c:10:xx:b3
    06:40:50  Default DROP  UDP 
    24.xx.xx.xx  :  500
    → 
    69.xx.xx.xx  :  500

    len=284  ttl=63  tos=0x00  srcmac=00:00:00:00:00:00  dstmac=00:1a:8c:10:xx:b3
    06:41:30  Default DROP  UDP 
    24.96.108.146  :  500
    → 
    69.73.11.234  :  500

    len=284  ttl=63  tos=0x00  srcmac=00:00:00:00:00:00  dstmac=00:1a:8c:10:xx:b3
  • 0
    The UDP 500 traffic is unrelated to your problem; it looks like the remote unit is trying to establish an IPsec connection, but you haven't configured one in your Astaro.

    If you are going through an Astaro PPTP service, you should not need any packet filter rules to access internal devices - the Astaro should create those and needed routes automatically.

    Cheers - Bob
  • 0
    Thanks for the help, The IPSEC connection request got me to digging a little deeper looking for differences between the working and non-working systems, and I noticed that my VPN Pool for PPTP on the working system was being served from a different subnet than that local LAN, while the non-working one was serving the VPN Pool for PPTP from the same subnet as the local LAN. I changed the non working one to a different subnet, and voila! everything started working again. I guess the VPN connection has to be a different subnet than the local LAN... I wonder if there is a way across the VPN to have access to my data stored on the work server... I can connect to web-based applications, but not my documents, etc... Any suggestions along those lines?