William Wicker
Forum Replies Created
-
And now I have a more complete solution. Things I did that ended up working:
* Change my Verizon plan to allow a fixed/public IP
* Add a single firewall rule: Allow incoming packets with a source port of 1194 (VPN)
* Use the “Custom” OpenVPN tunnel configuration
** I started this configuration from a throwaway “Server” OpenVPN configuration — used “Preview” to get the config file.
* Add a line in the custom config file to enable logging. (Custom OpenVPN configs don’t automatically get logging, but I didn’t know this until later.)
* Added a missing close quote in the push “route xxx.xxx.etc.etc” of my custom configuration (This is a fatal error! It will kill your OpenVPN dead!)
** Since I didn’t have logging turned on at the time, I discovered I had a problem via SSH: ps -A listed OpenVPN as <defunct>
** This in turn prompted me to figure out how to turn on logging.
** And to figure out how to get to the log (which, for “custom” configs, is not displayed in the web admin console.)
** The rest was reasonably straightforward, pretty much in line with my original expectations.Stuff I did NOT need to do:
* I did NOT need to configure both a VPN server AND a client on the rCell. (I did, of course, have to configure a client on my office computer.)
* Set up port forwarding in the firewall. (The push “route xxxx” was sufficient)
* Set up outbound firewall rules by hand.I have a partial solution. It turns out you need a Verizon data plan with a fixed / public IP to be able to see the rCell from outside. (Bring money!)
So now I have initiated contact from the outside to the rCell. I have a known-working communications link. That’s good!
Work on the OpenVPN configuration continues.
Now I have additional questions:
The manual seems to suggest that if I want to expose other devices on the rCell end of my VPN link I need to configure a VPN server (with a push route) AND a VPN client on the rCell. Surely this is not correct! Can anyone confirm or deny this?
