Posted: Fri Aug 01, 2008 17:40 Post subject: Re: RE: Port forwarding/NAT
dereks wrote:
I got the OpenVPN server to work. Basically, it's everything you said, plus this command:
Code:
iptables -I INPUT 1 -p udp --dport 1194 -j ACCEPT
...where 1194 is the default OpenVPN port.
Although I used the command line, you can supposedly save that line into the firewall rules using the web GUI. So I'm going to write a procedure to set up OpenVPN without using the shell at all, and then test it. Once I test it, I'll post it here (and/or on the Wiki).
bmatthewshea wrote:
Indeed to get this working I had to port forward my particular port under NAT/Port Forwarding, and point back to the local networks router address (one with server running). Shouldn't need this.
My testing disagrees here. I did not need to turn on port forwarding.
bmatthewshea wrote:
Also, you may need to make the router (server) pingable. (Under "Security" tab.) You may also want to uncheck "Filter WAN redirection" if you want to test the security portion from within local network. (As I have been doing.) Again these steps may only be necessary if testing from inside local net.
For "Filter WAN redirection", I agree, that's necessary to talk to the outside IP address from inside the LAN.
But I don't think turning on ping is necessary... I didn't explicitly check for that.
bmatthewshea wrote:
I also found out that the OpenVPN daemon will startup better if you run with the setting "Wan Up" as starting at system startup seems to cause problems. (Process seems to die.)
There is also a note about the process dying in the older Wiki docs. It talks about renaming some files... not sure why.
Cool.. I am glad you got it working. I will try that as a firewall rule when I get a chance to try remotely. Still wish it was more automated, not that I don't love dd-wrt. And yes, forwarding the port probably isn't necessary like I said..but this allows you to connect within the local network...at least I had to enable the forward or testing laptop(locally) wouldn't connect. (I wanted to connect locally just to test the certs/keys, before trying it remotely.)
I have read on openvpn web site? that you may need to make the router/hardware pingable? I don't like this either.. so hopefully not not needed.
I've collected all my info together and written a HOWTO. I edited my parent post (at the top) with the HOWTO. Please give it a look and let me know what you think.
Unfortunately, I don't have the necessary permission to post the HOWTO on the documentation Wiki, so maybe one of the regular devs can take that on.
I've collected all my info together and written a HOWTO. I edited my parent post (at the top) with the HOWTO. Please give it a look and let me know what you think.
Unfortunately, I don't have the necessary permission to post the HOWTO on the documentation Wiki, so maybe one of the regular devs can take that on.
Thanks for all your help!
Very thorough on my first read through. I like how you included OC (200 VS 250 Mhz) potential. Ha.
Thanks for reminding me about looking at logging (rejected) packets, also. Forgot it had that option.
Excellent work on this dereks. Following your notes, I'm working with a routed configuration using a Shimo client on Macosx connecting to an Asus dd-wrt server.
I had used the LAN subnet 192.168.1.xxx. Bad idea apparently. My first connection attempt using a wireless network having the same subnet connected, but would not pass data. Presumably the data was being routed to the local connection instead of the VPN tunnel. Changing the LAN subnet to something more obscure fixed that.
I also found my client reporting lzo errors so the comp-lzo line in the server solved that.
I agree with your earlier comment about the need for more thorough documentation. Take that comp-lzo command for example. Presumably there is a CPU load penalty to be paid in exchange for a bandwidth benefit. How much of each? And what about that "float" instruction of yours? No complaints - it works - but to optimize these systems, a more intimate understanding of various parameters would be helpful.
Excellent work on this dereks. Following your notes, I'm working with a routed configuration using a Shimo client on Macosx connecting to an Asus dd-wrt server.
Thanks for the feedback! Could you post the exact Model number of your router? I'd just like to document hardware that's been tested.
SteveDemy wrote:
I had used the LAN subnet 192.168.1.xxx. Bad idea apparently. My first connection attempt using a wireless network having the same subnet connected, but would not pass data. Presumably the data was being routed to the local connection instead of the VPN tunnel. Changing the LAN subnet to something more obscure fixed that.
...the VPN won't know how to route packets between multiple sites if those sites don't use a subnet which uniquely identifies them.
The best solution is to avoid using 10.0.0.0/24 or 192.168.0.0/24 as private LAN network addresses. Instead, use something that has a lower probability of being used in a WiFi cafe, airport, or hotel where you might expect to connect from remotely. The best candidates are subnets in the middle of the vast 10.0.0.0/8 netblock (for example 10.66.77.0/24).
And to avoid cross-site IP numbering conflicts, always use unique numbering for your LAN subnets.
SteveDemy wrote:
Take that comp-lzo command for example. Presumably there is a CPU load penalty to be paid in exchange for a bandwidth benefit. How much of each? And what about that "float" instruction of yours?
Well, in all fairness, this is a DD-WRT forum, not an OpenVPN forum. The "float" option is documented in OpenVPN, and the comp-lzo penalty-vs-benefit will depend entirely on your CPU and network environment.
The "float" was needed because the OpenVPN client first connects to the WAN I.P. address, but then it get packets from the internal LAN subnet (instead of the public WAN IP). If you don't have "float", OpenVPN gives an error because the packets are not coming from the WAN I.P. address. The "float" option is thus necessary whenever using a NAT firewall, which is the case with DD-WRT.
Posted: Sat Aug 02, 2008 21:13 Post subject: Local IP Conflicts (Same IP Network)
I know these issues are more OpenVPN in nature, but...it may help someone with ddwrt, also.
Network conflicts:
Have the same issue right now. Since most public networks I get on tend to be "192.168.1.x" and my (behind) router/server LAN is the same, I get the same problems. I can ping gateway/internet before I connect. After I connect I can ping only the server 192 address and both client/server on VPN network. Anything else on either "Local" network isn't pingable. I thought the VPN network/remote LAN should take priority? There are no conflicting host ip's. I am using OVPN on XP. I am working to fix this. About to try the float option and see if that does the trick. I used the float option to connect from inside my lan, but didn't add it when I tried remotely.
I have also noted that it may be best to use the "--up-delay" (or simpy "up-delay" in client config file) when using the Microsoft version of the OpenVPN client to access the VPN server. Seems if I don't, whether there was a authenticated connection or not, the TUN interface goes up. I have to manually Disable/Enable tun IFace to get it to see it is *not* connected. OpenVPN Gui "Disconnect" won't bring it down (corrctly) either. So this seems to help with that problem. I know this is more of a OpenVPN client-side issue, but thought someone might need it.
One other note:
I just started fresh using a linux server here to re-generate fresh .crt/.key's. (Originally used Windows and had nsCertType problem: != server.) I just wget'ed OpenVPN-2.1_rc9 to do this. Seems it works fine and generates a "server" nscerttype properly now, but the actual cert generated for server is always 5 hours ahead. (In other words the cert is only 'active' 5 hours in future from creation time.) My linux server is set to exact time as all other computers. Actually it is THE time server for all my computers, and feeds off a public time server. Date/hwclock etc all give accurate results. I tried to figure out why, but gave up.
Edit: No, I am not using the Linux server as VPN server. Just needed generate keys/certs and fix nscerttype problem.
Referenced Here.
Posted: Sun Aug 03, 2008 5:34 Post subject: Re: Local IP Conflicts (Same IP Network)
bmatthewshea wrote:
Have the same issue right now. Since most public networks I get on tend to be "192.168.1.x" and my (behind) router/server LAN is the same, I get the same problems. I can ping gateway/internet before I connect. After I connect I can ping only the server 192 address and both client/server on VPN network. Anything else on either "Local" network isn't pingable. I thought the VPN network/remote LAN should take priority? There are no conflicting host ip's.
Perhaps it is a firewall issue. Try disabling the SPI Firewall completely (as per the HOWTO). Does that change your results?
If so, you'll need to edit the last "iptables" line in the firewall configuration. (Edit it to match your OpenVPN server's private routing subnet.)
Posted: Sun Aug 03, 2008 6:10 Post subject: Re: Local IP Conflicts (Same IP Network)
dereks wrote:
Perhaps it is a firewall issue. Try disabling the SPI Firewall completely (as per the HOWTO). Does that change your results?
If so, you'll need to edit the last "iptables" line in the firewall configuration. (Edit it to match your OpenVPN server's private routing subnet.)
No luck there either. I also now have my LAN (behind router) on a totally different network then any public sites I know of.
Have you tried this on a XP box? It does ping the routers internal LAN address, but that is all it ever sees. So maybe it is actually getting stopped at router...? Seems like the router isn't forwarding from the local network? (other then itself)...
On the client side I know the route gets pushed successfully, and I see it in XP's routing table (with low metric). As I said, it can ping my router from 'inside', apparently.
Posted: Sun Aug 03, 2008 18:21 Post subject: Re: Local IP Conflicts (Same IP Network)
bmatthewshea wrote:
Have you tried this on a XP box? It does ping the routers internal LAN address, but that is all it ever sees. So maybe it is actually getting stopped at router...? Seems like the router isn't forwarding from the local network?
I have not tested under Windows XP. Doesn't XP have some kind of built-in firewall too? Perhaps the Windows XP firewall is causing a problem? Try disabling the XP firewall at the same time you disable the DD-WRT SPI Firewall, and see what happens.
If you disable the DD-WRT SPI Firewall, and still get this problem, then it must be a problem with either the OpenVPN configuration or your Windows XP box.
Since my HOWTO is based on a known-working configuration, you can also try pasting in the exact OpenVPN server, client, and firewall lines that I used in the HOWTO. I mean, paste it verbatim, using the same subnets, ports, and everything. (Be sure to use the DD-WRT backup feature to create a backup image beforehand, so you can easily restore it to your original settings after testing.)
If you use my posted configuration, and disable the Windows XP firewall and the DD-WRT SPI Firewall, and still have a problem, then you'll need to start sniffing packets and looking at log files. Turn on logging in DD-WRT (as per the HOWTO) and see if OpenVPN gives you any error messages.
Posted: Sun Aug 03, 2008 23:18 Post subject: Re: Private Network hosts not pingable.
dereks wrote:
bmatthewshea wrote:
Have you tried this on a XP box? It does ping the routers internal LAN address, but that is all it ever sees. So maybe it is actually getting stopped at router...? Seems like the router isn't forwarding from the local network?
I have not tested under Windows XP. Doesn't XP have some kind of built-in firewall too? Perhaps the Windows XP firewall is causing a problem? Try disabling the XP firewall at the same time you disable the DD-WRT SPI Firewall, and see what happens.
If you disable the DD-WRT SPI Firewall, and still get this problem, then it must be a problem with either the OpenVPN configuration or your Windows XP box.
Since my HOWTO is based on a known-working configuration, you can also try pasting in the exact OpenVPN server, client, and firewall lines that I used in the HOWTO. I mean, paste it verbatim, using the same subnets, ports, and everything. (Be sure to use the DD-WRT backup feature to create a backup image beforehand, so you can easily restore it to your original settings after testing.)
If you use my posted configuration, and disable the Windows XP firewall and the DD-WRT SPI Firewall, and still have a problem, then you'll need to start sniffing packets and looking at log files. Turn on logging in DD-WRT (as per the HOWTO) and see if OpenVPN gives you any error messages.
Good luck...
No.. I never run XP firewall software(built-in or otherwise) as long as I am behind a LAN/WAN router. Router is good enough as far as I am concerned.
I will take one more look at my networks, and maybe try your info as last resort. thanks, though.
Could it be the neighbor's router I am testing it on? I would think they would need VPN pass-through enabled. Can't really go in and look if you know what I mean. I will try taking it to a 'public' wireless network today, and see what happens.
Posted: Mon Aug 04, 2008 8:37 Post subject: Asus Router
dereks wrote:
Could you post the exact Model number of your router? I'd just like to document hardware that's been tested.
It's an Asus WL-500G Premium, based on Broadcom BCM4704 chip rev 9 running at 264 Mhz, using DD-WRT v24-sp1 ( 07/27/08 ) vpn (SVN revision 10011). OpenVPN, WDS, SSH port forwarding and normal router functions are all stable and performing well.
That fixes it. So the lines should be updated on 1st page to include these in firewall rules...
I don't know if you still need to forward the VPN Servers private network under the firewall.
This would probably amount to the same thing.
But I think the firewall rules need some more testing. I find it strange that you needed these lines, but I did not. I was pinging IP addresses across the VPN, and copying files with SSH, and I did not have those lines.
Also, since your new firewall rules specify the interfaces (br0 and tun0), I think my original rule that uses the OpenVPN subnet may be deprecated and/or superceded by your new rules above. So we may be able to boil down the firewall rules to a set that will work for all configurations, regardless of what subnet you are using for the OpenVPN configuration.
I just wanted to thank everyone in this thread. The help has been great. Still, I have a few questions.
I recently upgraded to SP1 (10108M). I previously had my router acting as a bridged openVPN server.
I liked the GUI interface and thought I'd give that a shot. Unfortunately, all the instructions here seem to be for a routed server.
I adapted my Config for the new file names and pasted everything in. The good news is that the OpenVPN server is running and I CAN connect from remote. The bad news is that I'm not getting an IP address assigned and seem to lack other connectivity.
Is it possible to setup a bridged network using just the openVPN GUI settings? Do I still need a startup script?
This is my current config:
mode server
proto udp
port 1194
dev tun0
keepalive 15 60
daemon
verb 3
comp-lzo
cipher AES-256-CBC
client-to-client
tls-server
ca /tmp/openvpn/ca.crt
dh /tmp/openvpn/dh.pem
cert /tmp/openvpn/cert.pem
key /tmp/openvpn/key.pem
tls-auth /tmp/openvpn/ta.key 0
But I think the firewall rules need some more testing. I find it strange that you needed these lines, but I did not. I was pinging IP addresses across the VPN, and copying files with SSH, and I did not have those lines.
Also, since your new firewall rules specify the interfaces (br0 and tun0), I think my original rule that uses the OpenVPN subnet may be deprecated and/or superceded by your new rules above. So we may be able to boil down the firewall rules to a set that will work for all configurations, regardless of what subnet you are using for the OpenVPN configuration.
--Derek
Yeah, I think this needs more testing. BTW the interface part was actually lifted from client config. (OpenVPN on wiki). I have it working, (before, too), but I am still dropping many packets. I do have it connecting to IP locally with just:
Seems to work with just the interfaces(w/o port forward), but seemed flaky. I don't seem to need to forward a network, though. Just these 3 lines?
Which brings up another problem. I have been running this about a day, and my router seems to be dropping connections half way through loading a web page. Do you know what this may be a sign of? Out of memory?
I stopped the OpenVPN process earlier today and sure enough the web pages that were not coming up, came up ... all of them. (only some were 'dying' halfway strangely enough)
Update:
I rebooted router with just those firewall lines, and seems to be running smoothly. I turned off logging of dropped/rejected packets in process. I will see how long it runs stable...
