Unknown OpenVPN issue

[rlcronin]

I can successfully establish a connection to the OpenVPN server in my RTN66U, but once connected I am having trouble using it. For example, I have a Linux box on the remote lan. I am unable to establish a vnc session to it over the vpn connection. However, I can rdp to a Windows box on the remote lan over the vpn and then vnc into the Linux box from there with no problem. I can ping the Linux box over the vpn with no problem.

The remote vnc used to work fine and I haven't changed the vnc or OpenVPN configuration on the machine I am attempting these connections from. The router firmware has been changed many times since I last had this all working (about a year ago).

What sorts of things might cause this? How do I troubleshoot it? Thanks for any help.
--
bc

An update, I have discovered that if I establish the vpn connection over a cell connection rather than over wifi then I am not having any problem. So, something on the wifi network is causing this. But why would rdp work fine and vnc, not? Aren't both just passed over the vpn connection? If I have a good vpn connection why would the underlying transport method matter?

 

[rlcronin]

In case this helps, here is what is logged when the remote machine connects to the vpn:

Jan 27 12:56:53 openvpn[3618]: nn.nn.nn.nn:50588 TLS: Initial packet from [AF_INET]nn.nn.nn.nn:50588, sid=20709890 a0230c9a
Jan 27 12:56:54 openvpn[3618]: nn.nn.nn.nn:50588 VERIFY OK: depth=1, C=US, ST=NN, L=nnnnnnnn, O=OpenVPN, OU=nnnnnn, CN=nnnnnnnn.asuscomm.com, name=nnnnnnnn.asuscomm.com, emailAddress=nnn.nnnnnn@gmail.com
Jan 27 12:56:54 openvpn[3618]: nn.nn.nn.nn:50588 VERIFY OK: depth=0, C=US, ST=NN, L=nnnnnnnn, O=OpenVPN, OU=nnnnnn, CN=sony-vaio, name=sony-vaio, emailAddress=nnn.nnnnnn@gmail.com
Jan 27 12:56:54 openvpn[3618]: nn.nn.nn.nn:50588 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Jan 27 12:56:54 openvpn[3618]: nn.nn.nn.nn:50588 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Jan 27 12:56:54 openvpn[3618]: nn.nn.nn.nn:50588 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Jan 27 12:56:54 openvpn[3618]: nn.nn.nn.nn:50588 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Jan 27 12:56:54 openvpn[3618]: nn.nn.nn.nn:50588 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Jan 27 12:56:54 openvpn[3618]: nn.nn.nn.nn:50588 [sony-vaio] Peer Connection Initiated with [AF_INET]nn.nn.nn.nn:50588
Jan 27 12:56:54 openvpn[3618]: sony-vaio/nn.nn.nn.nn:50588 MULTI_sva: pool returned IPv4=10.8.0.6, IPv6=(Not enabled)
Jan 27 12:56:54 openvpn[3618]: sony-vaio/nn.nn.nn.nn:50588 MULTI: Learn: 10.8.0.6 -> sony-vaio/nn.nn.nn.nn:50588
Jan 27 12:56:54 openvpn[3618]: sony-vaio/nn.nn.nn.nn:50588 MULTI: primary virtual IP for sony-vaio/nn.nn.nn.nn:50588: 10.8.0.6
Jan 27 12:56:56 openvpn[3618]: sony-vaio/nn.nn.nn.nn:50588 PUSH: Received control message: 'PUSH_REQUEST'
Jan 27 12:56:56 openvpn[3618]: sony-vaio/nn.nn.nn.nn:50588 send_push_reply(): safe_cap=940
Jan 27 12:56:56 openvpn[3618]: sony-vaio/nn.nn.nn.nn:50588 SENT CONTROL [sony-vaio]: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0,dhcp-option DNS 192.168.1.1,route 10.8.0.1,topology net30,ping 15,ping-restart 60,ifconfig 10.8.0.6 10.8.0.5' (status=1)

 

[extensi0n]

An update, I have discovered that if I establish the vpn connection over a cell connection rather than over wifi then I am not having any problem. So, something on the wifi network is causing this.

I have many sites using site to site OVPN's working with wireless clients without any issues.

Are you connected to a guest wireless SSID by chance?

 

[RMerlin]

I would take a look at the firewall configuration of the box you are unable to reach. VPN connection might come from an IP it does not recognize, and it would reject it by default.

 

[diyguy]

does it work by IP address? I am having an odd issue where all my RDP sessions only work via IP address and not hostname when connected via openvpn.

 

[rlcronin]

I would take a look at the firewall configuration of the box you are unable to reach. VPN connection might come from an IP it does not recognize, and it would reject it by default.

Where would I find firewall logs on RedHat Linux, do you know?

This vnc issue is not the only problem I'm having. Another issue is that I had the vpn server configured to have clients redirect Internet traffic through the vpn. That isn't working either. When I try to browse a website after connecting to the vpn, the browser just sits there spinning. Even if I point it at 192.168.1.1 to try to get to the router gui.

I had to change the server config to not have the clients redirect Internet traffic. Thereafter I can get to, for example, google.com, but still cannot get to the router gui.

I figure these problems are likely related somehow, I just don't know what underlying issue might cause these problems.

I notice a new Firewall choice in the router's vpn server configuration. I don't recall that being there before. What should that be set to? It seems to default to Auto. Might this be related somehow?

Another weird thing I noticed, I use putty to ssh to the box mostly to tunnel the vnc session over. I changed the ssh config to stop suppressing the shell. When I start putty, I now see the shell session start as expected. If I type in some simple commands with only a few lines of output (e.g. pwd or ls in a directory with only a few files), it works fine. If I type a command into the shell that outputs more 6 or 8 lines (e.g. ls) then I get no output at all and the shell session seems to freeze up. Perhaps this is why the vnc session doesn't work as well.

Any further thoughts? If this were a firewall issue the shell session wouldn't work at all I think.
--
bc

 

[rlcronin]

does it work by IP address? I am having an odd issue where all my RDP sessions only work via IP address and not hostname when connected via openvpn.

I am not using hostnames at all, just IP addresses.
--
bc

 

[rlcronin]

I thought maybe this might be some sort of mtu issue so I played with ping until I found the point where fragmentation occurred. This is the result:

C:\Users\Bob>ping 192.168.1.20 /l 1472 /f

Pinging 192.168.1.20 with 1472 bytes of data:
Reply from 192.168.1.20: bytes=1472 time=81ms TTL=63
Reply from 192.168.1.20: bytes=1472 time=69ms TTL=63
Reply from 192.168.1.20: bytes=1472 time=69ms TTL=63
Reply from 192.168.1.20: bytes=1472 time=68ms TTL=63

Ping statistics for 192.168.1.20:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 68ms, Maximum = 81ms, Average = 71ms

C:\Users\Bob>ping 192.168.1.20 /l 1473 /f

Pinging 192.168.1.20 with 1473 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 192.168.1.20:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

So 1472 is the largest ping size before fragmentation happens. Might this somehow be related to the problems?

Grasping at straws obviously ...
--
bc

 

[diyguy]

It sounds like firewall somewhere. this is one of those pull your hair out problems. Maybe a restart of VNC on the linux box ? I know its working from other sources, but maybe it needs a refresh.

 

[extensi0n]

http://michael.stapelberg.de/Artikel/mtu_openvpn

or

http://networkcanuck.com/2013/06/10/troubleshooting-mtu-size-over-ipsec-vpn/

That help?

 

[rlcronin]

http://michael.stapelberg.de/Artikel/mtu_openvpn

or

http://networkcanuck.com/2013/06/10/troubleshooting-mtu-size-over-ipsec-vpn/

That help?

Very clear and makes sense, but sadly adding link-mtu 1472 to the server and client configuration and restarting everything didn't change anything. Oh well, I guess I am just stuck using the rdp method until I can get back to where the router is (I'm 1,000 miles away from there for the next 3 weeks and kicking myself for not having tested this before I left despite the fact that it all worked a month or two ago).

It is still very mysterious that I can ping various addresses on the remote lan (e.g. a Linux box at 192.168.1.20, a Windows box at 192.168.1.124) but not the router itself, 192.168.1.1. Not to mention the other weirdness with ssh, vnc, etc. Baffling.


bc

 

[rlcronin]

Just to close this out, I managed to ferret out the cause of this. The wifi network I am on is using Ruckus Wireless gear. Said gear suffered an ssh vulnerability in 2013. The recommended mitigation was to firewall off ssh traffic to the access point. The place I am staying went a bit further than that, they firewalled off all ssh traffic. So I am unable to get a working ssh connection to my remote Linux box. Since the Linux box is locked down in such a way that the only way I am able to vnc into it is via an ssh tunnel, I'm basically screwed unless I can somehow modify the Linux box's firewall configuration remotely to permit direct vnc sessions into the box (so that I would not have to use ssh).

I tried to get into the firewall configuration remotely over a vnc session from a Windows box on my lan (which i am using rdp to get to) but I get a cryptic error "org.fedoraproject.slip.dbus.service.PolKit.NotAuthorizedException.org.fedoraproject.config.firewall.auth" and a REDO or QUIT button (and REDO doesn't work). I am guessing there's no way for me to mess with the firewall remotely and that I am simply going to have to use the indirect rdp to the Windows box and vnc from there until I can get back.

Thanks everyone for your suggestions.

I'm not so sure I'm a fan of Ruckus. I think I'll be looking for somewhere else to stay the next time I'm away that doesn't use Ruckus gear. Sigh.
--
bc