Cryptostorm VPN issue, and Parameter Question. Not sure if this should be in networking :P
 

Okay, so I'm currently on Fedora 25: 4.9.9-200.fc25.x86_64.
I'm trying to configure Cryptostorm via OpenVPN.
When I try to use the TCP version of their VPN I receive the error.
--replay-window only makes sense with --proto udp
I can't find the replay window option anywhere in conf files etc.

Here's the info crypto gives:
If your connection hasn't succeeded, or you are in fact "hung" and unable to send or receive data after connecting, then looking at your error log will be useful in seeking assistance from our support team or other network members in the community here. That logfile is called "devnull.txt," and will be saved into the same directory as your config file. You can change the verbosity of that error log - how much detail it contains - with the "verb" parameter in the config itself (it goes from zero, no detail, to nine - enormous detail). Common issues holding up successful connections include local firewall rules, local routers that refuse to cleanly transmit cryptostorm network sessions, and on rare occasions ISP-based blocking or session-hijacking attempts

any info helps...
can't find any posts or info anywhere.
Thanks
edited to apologize for not reading the main thread on networking didn't see/read it till after posting lol
-V

OK so I'm guessing all I have to do is edit a .conf file, but when I grep I find nothing for replay-window to try to get tcp file to work. Found how to add the verb parameter but can't find anything involving the replay window.

I have written a lot of things here about how to configure OpenVPN and how to properly diagnose connection issues.

You should use the UDP, not TCP, protocol for OpenVPN.

As I have said previously (and so, won't repeat now), OpenVPN basically acts like a network router which just happens to be implemented in software and which just happens to be secure. You should therefore break the problem down much as you would have to do with any router:

1. Do the routers successfully connect to one another? Can their encrypted packets flow in both directions between them? Do they successfully complete their negotiations? (Remember that OpenVPN is designed to tell you nothing until it knows that you're a friend. It might not even respond.)
2. Once you have confirmed this much, it becomes a simple TCP/IP routing problem. (At this point, "it's just a router.") You have "virtual subnets" that represent the OpenVPN client (and server), usually on 10.8.0.x, and you also have other remote subnets. Traffic must successfully flow in both directions between them. If any of those packets wind up being "routed to the Internet at large," they will be discarded. Everything must be routed the way you want it to be, both when the tunnel is up and when it's not. Remember that DNS-server entries usually must also change because DNS-servers won't respond to "everyone anywhere."

traceroute is your friend. So is tcpdump (or WireShark).

Good to know, however I don't imagine the problem I'm facing has anything to do with what you just said expect for your opinion on tcp/udp. I feel as if all I need to do...now that I've searched around a bit is change some conf comments lol.
It seems that way at least. I'm not having connection issues (not yet or maybe at all), only a problem finding where the option I need to change is, and I cannot find your diagnosis postings. I'm not fluent with this site much, although I'll keep looking (: