Ok, I got it working again. Unfortunately I don't know what the problem was. I punted and set everything up exactly as in this guide and it worked and then started adding what I wanted back.
Somethings I have learned:
1. Accessing the router via httpS can cause problems. More than 50% of the time when I saved the settings in the Services tab, the private key would get truncated and other changes I had made would not get saved. I switched back to http and I have not had that problem yet. This made testing quite frustrating
2. Port-share does not work when https is running on the router. OpenVPN complains that something is already bound to that port and dies.
3. the "group nobody, user nobody" doesn't work out of the box. My linux skills are weak, but I assume I need to create a new user and with low privileges. Any help on how to accomplish this on dd-wrt? This is the last of the important hardening tips I need to put in.
4. I have been able to get DH with 2k keys, AES-256-CBC, tls-auth and ns-server-type directives to work. OpenVPN warns me I need to secure the private key better. I would also like to implement the chroot (jail) technique.
5. In my very limited experience, it seems that port 1194 is frequently blocked. Yet I when I could I would like to use 1194/udp, but it seems like I need to also have tcp on another port available like 443. So my next task is to get openvpn instances on other ports. I find it ironic that because of strong firewalls everything except 443 and 80 are locked down. So what do all the programs do? Run everything over 443 (Hamachi, skype, openvpn, etc. defeating the purpose of having thousands of ports available and creating another NATlike problem.
6. I would like to have the ability from the client side to determine if I want WINS, DNS, etc. traffic to go over the VPN. Yet the commands I see right now are sever side. Can you control that from the client side via an .ovpn file? It would be nice to be able to control if I am in routed or bridge mode from the client. Then I could have Road Warrior connections and a PtP network between various remote sites.
7. Since I have been spending a lot of time with syslogd. I have been made aware of how frequently my firewall is beat upon. Usually 2-3 different ip addresses per day probe a large number of ports on my system.
rearden
This is it! If you follow this you can set up a pretty good, bridged firewall. And listen to iTunes! How you handle the client is up to you. I use OS X and Viscocity.
the problem is that 24sp1 with VPN has no jffs partition. There are some posts about this issue on the forum. So the question is, what would the best way be to get this running ?
the problem is that 24sp1 with VPN has no jffs partition. There are some posts about this issue on the forum. So the question is, what would the best way be to get this running ?
I believe a stripped down version of the VPN build with space for Jffs is currently being built by Eko. You shouldn't be using SP1 anyway given all its bugs.
Joined: 14 Oct 2006 Posts: 296 Location: Sector 001
Posted: Tue Mar 10, 2009 14:04 Post subject:
Greetings all and thanks for a great thread. I've been able to get OpenVPN working fine using the TUN / Layer 3 / Routing method found here. I've actually have had an idle link open for several days and it seems quite solid.
When I came across this thread, I thought I'd give it a try. Mostly to learn from the experience and also decide on my own which method would be best for my applications.
The good news is I got it working ok using the directions described in this thread. However, it only will stay up when idle for ~10min. What happens is even though the Windows OpenVPN client thinks all is well, the logs on the server side will have the following entry (ip address has been modified):
The link still shows active on the client but I'm no longer able to access anything on the VPN anymore. After about an hour of idle time. The client logs will start to fill up with the following:
Quote:
Tue Mar 10 07:33:55 2009 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Mar 10 07:33:55 2009 TLS Error: TLS handshake failed
If my configs are needed for troubleshooting, I can do that but they are almost verbatim to what was on this thread.
Any suggestions / help would be greatly appreciated. If not, I guess I'll just be using the routing method since I know that does work.
Joined: 12 Dec 2007 Posts: 764 Location: Pittsburgh, PA USA
Posted: Wed Mar 11, 2009 12:41 Post subject:
I've been a big fan of the static key mode on OpenVPN for some time, but there's always a better way, and I've occassionally worked on the certs it since v24sp1. I followed the instructions in this thread and it almost worked. After bumping the client and server up to "verb 9" and pouring through logs, I finally got it working. A couple of things I had to change.
Code:
mode server
client-to-client
tls-server
server-bridge
dev tap0
proto udp
keepalive 10 120
comp-lzo
dh /tmp/openvpn/dh.pem
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/cert.pem
key /tmp/openvpn/key.pem
I had to take out the IP range on the server-bridge statement, otherwise, my clients weren't picking up an IP address.
The other key was to wait. I'm in US Eastern time, which is currently GMT -6. When you create the certs, it creates them in GMT, so the logs were showing that the cert was not yet valid. That drove me nuts more than anything. Next morning, it connected right up, and once I figured out the server-bridge setting, all was well. _________________ __________________________
Netgear R7800
DD-WRT v3.0 STD
Linksys WRT1900AC
DD-WRT v3.0 STD
Joined: 14 Oct 2006 Posts: 296 Location: Sector 001
Posted: Fri Mar 13, 2009 20:32 Post subject:
dpp3530 wrote:
I had to take out the IP range on the server-bridge statement, otherwise, my clients weren't picking up an IP address.
Interesting, I was not aware it was syntactically legal to omit IP ranges from the server-bridge parameter. I always thought that if you don't use it, just leave it out completely. So in hopes to resolve my little problem, I added "server-bridge". As it turns out, openvpn no longer starts up on the router. Comment it out, back in business.
What happens if you leave your connection up and idle for several hours? (see my previous post for my symptom)
dpp3530 wrote:
The other key was to wait. I'm in US Eastern time, which is currently GMT -6. When you create the certs, it creates them in GMT, so the logs were showing that the cert was not yet valid. That drove me nuts more than anything. Next morning, it connected right up, and once I figured out the server-bridge setting, all was well.
Ahhh, that explains the wait time. I never really understood why my freshly created keys would not work until the next day. Thanks for the tip!
Joined: 12 Dec 2007 Posts: 764 Location: Pittsburgh, PA USA
Posted: Fri Mar 13, 2009 22:36 Post subject:
phlegmer wrote:
What happens if you leave your connection up and idle for several hours? (see my previous post for my symptom)
I had the same issue. I added two lines on the client side and it seems to have resolved it
Code:
keepalive 10 120
float
The keepalive is what actually resolved it, I think. The float is there in case Verizon decides to issue me a new IP (been happening quite a bit lately). Without it, it will only talk to the IP it initiated connection with, so if it changes, I get dumped.
So, in short, my client config is
Code:
remote myserver.dyndns.org 1194
persist-key
tls-client
proto udp
ca ca.crt
nobind
persist-tun
cert cert.crt
comp-lzo
dev tap
key key.key
ns-cert-type server
verb 3
resolv-retry infinite
keepalive 10 120
float
Joined: 12 Dec 2007 Posts: 764 Location: Pittsburgh, PA USA
Posted: Fri Mar 13, 2009 22:45 Post subject:
phlegmer wrote:
Interesting, I was not aware it was syntactically legal to omit IP ranges from the server-bridge parameter. I always thought that if you don't use it, just leave it out completely. So in hopes to resolve my little problem, I added "server-bridge". As it turns out, openvpn no longer starts up on the router. Comment it out, back in business.
If I comment out the "server-bridge" I can't get connected, but leave it there without a range, it works.
I believe it's only legal in OpenVPN 2.1. From the man page for OpenVPN 2.1:
Quote:
If --server-bridge is used without any parameters, it will enable a DHCP-proxy mode, where connecting OpenVPN clients will receive an IP address for their TAP adapter from the DHCP server running on the OpenVPN server-side LAN. Note that only clients that support the binding of a DHCP client with the TAP adapter (such as Windows) can support this mode.
Joined: 14 Oct 2006 Posts: 296 Location: Sector 001
Posted: Mon Mar 16, 2009 14:59 Post subject:
dpp3530 wrote:
I believe it's only legal in OpenVPN 2.1. From the man page for OpenVPN 2.1:
Quote:
If --server-bridge is used without any parameters, it will enable a DHCP-proxy mode, where connecting OpenVPN clients will receive an IP address for their TAP adapter from the DHCP server running on the OpenVPN server-side LAN. Note that only clients that support the binding of a DHCP client with the TAP adapter (such as Windows) can support this mode.
BS updated OpenVPN in 10969.
Interesting that you bring up the BS build. I was just about to post a question to find out what is the latest "best" build to use for OpenVPN. I'm still using v24 SP1. Never used any of those type of builds before. Part of the reason was there's always so many to choose from. Why there's two branches (Eko and BS) is still beyond me.
Anyway, BS 10969 is the recommended latest stable OpenVPN build? Are the builds cumulative? Would be handy if that OpenVPN status tab would be usable.
Joined: 14 Oct 2006 Posts: 296 Location: Sector 001
Posted: Mon Mar 16, 2009 21:42 Post subject:
The keepalive option included in the client config seemed to have solved my problem! It has been idle for several hours and it's always up when I check it now. Which raises the question if keepalive is still needed in the server config?