notorious.dds

If their IT department's employees are worth the paychecks they receive, they already know what's possible and what isn't.

You should be able to connect to an FTP server. As far as I can tell, RCI's firewall is using DPI to block traffic with headers that reveal a VPN connection.

It's been a few months since I was on board (December 2018), but I ran a number of tests while I was there trying to connect to different types of VPN servers. All of the servers I tested were run by me personally. In other words, I did not test any commercially available VPN services. That said, the commercially available services typically use some variation of the methods used in my tests. Here's what I found: TLDR: The only VPN connections I could make work required that the connection be wrapped in an SSH connection. Here's the list of VPN connection types that would NOT connect while using VOOM internet on board RCI's Harmony of the Seas: PPTP (default port) L2TP/IPSEC (Sonicwall Global VPN Client using default ports) SSL VPN (OpenVPN using UDP protocol, default port 1194, no TLS key authentication) SSL VPN (OpenVPN using UDP protocol, non-standard port, no TLS key authentication) SSL VPN (OpenVPN using UDP protocol, port 443, no TLS key authentication) SSL VPN (OpenVPN using TCP protocol, default port 1194, no TLS key authentication) SSL VPN (OpenVPN using TCP protocol, non-standard port, no TLS key authentication) SSL VPN (OpenVPN using TCP protocol, port 443, no TLS key authentication) SSL VPN (OpenVPN using UDP protocol, default port 1194, TLS Direction = Encryption) SSL VPN (OpenVPN using UDP protocol, non-standard port, TLS Direction = Encryption) SSL VPN (OpenVPN using UDP protocol, port 443, TLS Direction = Encryption) SSL VPN (OpenVPN using TCP protocol, default port 1194, TLS Direction = Encryption) SSL VPN (OpenVPN using TCP protocol, non-standard port, TLS Direction = Encryption) SSL VPN (OpenVPN using TCP protocol, port 443, TLS Direction = Encryption) Here's what would actually connect: SSL VPN tunneled through an SSH connection (OpenVPN using TCP protocol - port utilized and existance of a TLS key were unimportant) As I mentioned earlier in this thread, RCI is clearly taking an active approach to blocking VPN use. Further, the only test of mine which succeeded was the one in which tunnel overhead was GREATEST. This fact plainly dismisses the earlier assertions (made by those who relied on virtuoso arguments to support their claim) that VPN connection issues were the result of "network latency". My speculation is that those who are currently able to successfully get their VPN to connect while using VOOM are able to do so because their VPN service already utilizes some sort of obfuscation (i.e. SSH tunneling) or possibly VOOM has whilelisted some VPN servers for some companies. For what it's worth, I haven't yet found a network that successfully blocks my VPN connection when it's wrapped inside and SSH tunnel. (On some networks - not VOOM, I've had to use the SSH server's acutal IP address because the network wouldn't resolve my server's domain address... but that's about it). Lastly, If you're looking for a commercial VPN service that will work while on board any RCI ship, I'd recommend getting one which is already known to work from within China. This ought to give you the best chance of getting around RCI's rediculous firewall.

Pretty much. I don't know that I'd be a big fan of routing all of my network communication through Kaspersky's servers, but that's up to you. It doesn't sound to me like you really have an overwhelming need using the VPN anyway. In my case, I've set up my own VPN server(s). The main purpose is so that I can connect to my home or office from wherever I happen to be. However, I have used it to evade packet filtering while connected to some retailer's "free wifi" that subsequently filters out traffic headed for Amazon or other any of its competitors. In an effort to bring this thread back on topic, it sounds as though RCI's VPN restrictions have loosened since last December based upon nneul's post. Since my experience with RCI's Voom wireless, I've discovered numerous other public wifi networks that also block VPN usage. In all cases, I've been able to get around the block by tunneling my VPN through an SSL connection. I never tried this while connected to Voom, but I was hoping to do so when I'm back on board this December. However, this may be unnecessary based upon nneul's post. Regardless, I have a series of tests that I'm prepared to run while on board. I'll post my results once I have them.

I don't really see any of this software as giving you "privacy" per se. However, it should keep you out of hot water with regards to entering personal info into fake websites designed to look like you bank's website, downloading viruses, etc. The reason I wouldn't call this "privacy" is that anything you do on that public network could be visible by other users and is almost certainly viewable by the network operator. For instance, they could see that you visited your bank's website, but they wouldn't be able to get your password... assuming it was encypted which it almost certainly would be. And, for what it's worth, US Intelligence advocated that Kaspersky software not be used by essentially anyone last December. Subsequently, a mandate was given to all federal agencies to remove it from their machines. Other than that, I woudn't worry too much.

I rescind my earlier statement about you likely knowing more about this topic than I.

It appears to me that RCI is blocking the same VPN's that the government of China has also figured out how to block. In other words, if you're using an IPSEC or PPTP VPN, you could be okay. If you're using an SSL VPN with an encrypted control channel, you could be okay. If you're using an SSL VPN with an unencrypted control channel, you're screwed. If you're using a publicly available VPN service whose server has been blocked by RCI's firewall, you're screwed regardless of the type of VPN. This isn't yet confirmed, but I'd be willing to wager on it. Also, I agree. RCI needs to fix their FAQ specifically stating that you can use VPN's.

It looks like Windscribe could be a good testing tool. From the Windscribe FAQ: So next question, can anyone using Windscribe connect using stealth mode?

I'm not super familiar with AnyConnect. However, a cursory reading of the application appears to suggest that the control channel is always made via TCP. It seemed to me that even if your connecting via UDP with AnyConnect, the control channel remains as a TCP connection. I think this could be important later, see below. Also, it appears that the control channel is encrypted by default with AnyConnect. If true, this would get you past DPI. With OpenVPN, encrypting the control channel has only become possible with the most recent releases of the program. In fact, if you're only looking at "stable" releases, the first release in which control channel encryption became available was 2.4.4 which just came out in September. Was your OpenVPN server configured with UDP or TCP? I'm not aware of any TCP connection through which a UDP OpenVPN connection can be made. All of the OpenVPN tunneling procedures with which I'm familiar require that OpenVPN use a TCP connection. I appreciate your response and, at this point, concede that you likely know more about this topic than I. However, I felt your statement of: "When something doesn't work lots of people mistakenly assume it some devious plot by the cruise lines to block it. Sometimes though its just the nature of satellite internet" to be a little dismissive. I'll will admit that is may have ruffled my feathers a bit . However, I'm over that. Regardless, I still don't buy the latency argument. What I'd like to know about VOOM with regard to VPN's is the following: Can anyone successfully tunnel a TCP OpenVPN connection via AnyConnect, SSL, SSH or otherwise? If using a newer release of OpenVPN that can utilize the --tls-crypt (aka encrypted control channel) option, can a connection be made? If so, does it work both with both UDP and TCP connections? The only thing I could have tried while on board but didn't was to tunnel the VPN through and SSH connection. I didn't think to try that until it was too late. I guess that's what the next cruise is for! Fair question. It was running on my router. I know, I know... but it works. However, since this frustrating experience, I've since set it up on my linux box at home where I can compile and install the lastest version of OpenVPN thereby allowing me to use --tls-crypt. I've also configured a route to my work from this server via a regular OpenVPN tunnel. This allows me to evade DPI and get to both my home and office with setting up a new server at the office as well.

Hi Matt, I read somewhere in my exploration that AnyConnect will work on board. That said, I have not tested it. I'm near certain that the blockage is due to use of DPI on VOOM's firewall. What I don't know is if: 1. They've configured it to allow certain VPN connections and not others, OR IF 2. The people who are getting through on their VPN's are using services that utilize obfuscated control channels thereby evading the DPI. Also, for the record, I don't buy twangster's argument that the VPN failure is due to latency. Here's why: 1. While I was on board, my VPN connection attempts ALWAYS failed during the TLS handshake. 2. As I mentioned earlier, their web content filter blocks access to many websites that simply discuss VPN's. This alone suggests that they are "anti VPN" at RCI. 3. He states that OpenVPN can't handle lag but that "SSL VPN and IPSEC VPN work fine on Voom, even the geosync satellites with 600+ms latency". OpenVPN is an SSL VPN, so I'm not so sure he is an expert about which he speaks. Circumventing the blockage via changes only accessible to the end user is tough. If you're VPN provider doesn't offer obfuscated/stealth connections, SSL tunneling, or SSH tunneling, it would require that the user set up his own server to which the user could connect while on board. Then, that traffic would have to be routed from the user to their personal server and then through another tunnel that can connect with their desired VPN provider. That's probably very unrealistic for your average user. Thanks! I like too.

One option is to bring a router with you that supports WISP mode such as the TRENDnet TEW-817DTR. This option would allow you to share a single connection with mulitple devices. It would mean that the connections would have to occur within range of the router (unlike traditional connections that work anywhere on the ship.) But, it could be a good money saver. Using a router in WISP mode is much like using a traditional wireless router with one main difference: The router itself is connected to the internet wirelessly as opposed to being connected via ethernet wire. By using a router in WISP mode, the router is the device which gets athenticated to VOOM. The first client connected to the WISP router will be asked to authenticate to VOOM. Once authenticated, subsequent devices that connect via the WISP router get to share the connection without additional authentication. I just did this last week (December 2017) on the Oasis using an old router that I loaded with a 3rd party firmware (DD-WRT) and configured it to work in WISP mode. It worked great. That being said, the WISP router will loose its internet (and subsequently, so will all of the devices connected to it) if you try connecting directly to VOOM using the same access code that was already used to authenticate the WISP router. In your situation, if all 3 of your state rooms are adjacent to eachother, one WISP router might be able to cover all three. If that's the case, you might consider buying one code just for the router. This would give internet access to EVERYONE in your family for the cost of ONE device.

It seems that this rep states at the end of the interview why they block VPNs. However, I couldn't quite understand what the reason was from the video. Does anyone else have any insight into why the VPNs are blocked? Honestly, I'm struggling to come up with a plausible reason.

Hi guys, I just wanted to put my 2¢ in here. I just got off the Oasis on 12/31/2017. My VPN was most definitely blocked. It has nothing to do with my company's settings. I can say this because I'm the one who set up the VPN that I utilize and there's nothing preventing this connection from my server's end. Further, this reality is tacitly confirmed simply by performing web searches via VOOM that involve the word "VPN". Clicking upon links from those searches results in pages that are blocked by VOOM's content filter. In other words, not only do they activity block VPN connections, but they also go out of their way to obfuscate information one might be able to obtain via web searches that could assist in getting around the VPN connection block. It's important to note that I was trying to connect via OpenVPN. And, although I couldn't get my VPN working, I still had connectivity to my VPN server via an SSH connection. With that SSH connection, I was able to manipulate my VPN server's settings. Subsequently, I fiddled with my VPN's settings to see if I could get it to work. I tried the following: non-standardports UDP connections TCP connections TCP connections via port 443 ... and nothing worked. Because I set this server up myself, it was also using an unknown URL for the connection (ie not privatetunnel.com or or nordvpn.com, etc) With those tests, the only conclusion I can make is that the means of VPN blocking by VOOM is Deep Packet Inspection (aka DPI). Blocking VPN's by way of DPI is well known by anyone using VPN'S in countries whose governments try to block them (ie Syria). The good news is, there IS a way to evade VPN blocking by DPI. It's commonly referred to as Stealth or Obfuscated VPN. I speculate that those who ARE still able to connect to their VPN's are probably already using Obfuscated connections. With this frustrating experience of being blocked from my server while on a non-free wifi connection, I have subsequently converted my VPN server so that it now uses obfuscated connections. However, I won't be able to test this setup for another year when I set out on my next cruise.