RDP IS DISCONECTED WHEN IN MOBILE VPN

[vasgogo]

Hello all, 

Recently we upgrated 5000 series to R81. 10 from R80. 20. After the upgrade the windows users are complying about frequent disconnections from RDP and other services(like SQL).

Has anyone encountered this problem, and if yes how did you solve it?

Thank you

[PhoneBoy]

Have you taken tcpdumps and the like to see what is happening when applications are failing?
I suspect you’ll need to involve the TAC.
If you haven’t already, make sure to install the latest GA JHF.

[vasgogo]

Hi ,

I have involved TAC, but nothing so far. I had the last JHF (take 66), but I uninstall it to default one as it was not working.

when I run zdebug I receive the below log:

@;144306869;[cpu_1];[fw4_0];fw_log_drop_ex: Packet proto=6 192.168.10.45:1433 -> 172.16.0.10:55173 dropped by vpnktcpt_chain_out Reason: vpnk_tcpt invalid negative tunnel id;
@;144307543;[cpu_1];[fw4_0];fw_log_drop_ex: Packet proto=6 192.168.10.45:1433 -> 172.16.0.10:55173 dropped by vpnktcpt_chain_out Reason: vpnk_tcpt invalid negative tunnel id

TCP dump didn't show anything.

[PhoneBoy]

You’ll need to work with TAC on troubleshooting this since it’s clear the traffic is not being routed out of the gateway.

[vasgogo]

hi,

I run zdebug and during the disconnection we saw the below:

@;144306869;[cpu_1];[fw4_0];fw_log_drop_ex: Packet proto=6 192.168.10.45:1433 -> 172.16.0.10:55173 dropped by vpnktcpt_chain_out Reason: vpnk_tcpt invalid negative tunnel id;
@;144307543;[cpu_1];[fw4_0];fw_log_drop_ex: Packet proto=6 192.168.10.45:1433 -> 172.16.0.10:55173 dropped by vpnktcpt_chain_out Reason: vpnk_tcpt invalid negative tunnel id

I have involved TAC but nothing so far. The odd thing is that users with MAC OS did,t experience any problem.

I had take 66, but I uninstalled it to check if the user was solved but nothing.

tcpdump was normal.

[Peter_Lyndley]

I came across a similar problem when the gateways in question were running QoS blade (in both R81 and R81.10)

Either you can turn this off (if that is a sensible workaround for you), or try using fast_accel on the connections that you need to keep working.