For each client name, the commonn name you used when you created your certificate. You also need to put the appropriate IP range. You can also >> append a second line if you have more than one subnet at the remote location. For example
I already tried iroute, bu thanks to your post I just realized I made a mistake when using it ; for the client name I didn't payed attention to the common-name used when creating certificate...
I will try it again, it should work better
MrFidget wrote:
These files allow the server network to see the clients. Also means that client Internet traffic does not travel through the server's connection.
My goal is to redirect the client internet traffic through the VPN ; so I'm going to have a new issue, even if I still using the "redirect gateway" option ?
The server network has 3 VLANs for Voice, Data and a Guest VLAN which has no access outside of the 172.17.102.0/24. The other networks can see resources, such as printers in this subnet.
The client site has a single VLAN with 2 phones, 2 PCs and a printer or two. No need to split.
Each site has local Internet, however I am sending windows AD dns queries to the server network's Windows servers. Split DNS.
Have a look through these and compare them with what you have
Since my TLS cipher is OFF, my config file miss only "management 127.0.0.1 5002" -> it could explained these errors in my logs (both on server and client side) :
Quote:
20120604 23:41:22 MANAGEMENT: Client connected from 127.0.0.1:5001
20120604 23:41:22 D MANAGEMENT: CMD 'state'
20120604 23:41:22 MANAGEMENT: Client disconnected
20120604 23:41:22 MANAGEMENT: Client connected from 127.0.0.1:5001
20120604 23:41:22 D MANAGEMENT: CMD 'log 500'
If I reboot my VPN server, the client is unable to reconnect :
N RESOLVE: Cannot resolve host address: myserverdomain.dyndns.org: [HOST_NOT_FOUND] The specified host is unknown.
It's very strange, if I put the ip adress of the server name instead of the domain name, the error doesnt occurs anymore... Apparently, I'm not the only one to have this issue... is it a bug ?
I have another strange behavior ; if I disable openVPN on the client router I can connect to the web GUI from anywhere (using the client domain name, port 8080), but once openVPN is setup and connected it's not working anymore (even with telnet), after a few minutes I have this error in my browser :
Quote:
The system cannot communicate with the external server ( myclientdomain.dyndns.org ). The Internet server may be busy, may be permanently down, or may be unreachable because of network problems.
Please check the spelling of the Internet address entered. If it is correct, try this request later.
If you have questions, or feel this is an error, please contact your corporate network administrator and provide the codes shown below.
Notification codes: (1, GATEWAY_TIMEOUT, myclientdomain.dyndns.org)
And this behavior only happen on the client side... The openVPN server remain accessible from anywhere at anytime...
I got caught with a misspelled common name in the client certificate. Did sort of what you are describing, kiilled LAN access. Had nme screwed. Some sleep and I made it work. Maybe the same for you ?
There is / has been an issue with DynDNS.
If you are stuck with dynamic DNSs, it makes life a little harder. All of my deployments are static.
I've been flat out at the moment on an Asterisk, OpenVPN & SER (milkfish maybe or even a compiled Kamailio) project to connect a commercial IP PBX system securely to a public SIP switch.
Ill have a closer look when I get a moment, btu I am on a deadline and working during a public holiday here in au.
Thanks for your support I tried to sleep, and sleep again, and again, but no results. Maybe that the way to go is to try mushrooms. I *have to* be able to see in the matrix.
Joined: 08 Jun 2012 Posts: 11 Location: Fayetteville, TN
Posted: Wed Jun 13, 2012 15:11 Post subject:
First, it isn't necessary to push the route of the vpn subnet. OpenVPN will create that route automatically.
You posted:
Quote:
20120603 15:41:58 WRTT54GL/xx.xx.xx.xx:2048 MULTI: bad source address from client [192.168.0.1] packet dropped
20120603 15:42:00 WRTT54GL/xx.xx.xx.xx:2048 MULTI: bad source address from client [192.168.0.1] packet dropped
20120603 15:42:00 WRTT54GL/xx.xx.xx.xx:2048 MULTI: bad source address from client [192.168.0.1] packet dropped
20120603 15:42:01 WRTT54GL/xx.xx.xx.xx:2048 MULTI: bad source address from client [192.168.0.1] packet dropped
20120603 15:42:01 WRTT54GL/xx.xx.xx.xx:2048 MULTI: bad source address from client [192.168.0.1] packet dropped
20120603 15:42:07 WRTT54GL/xx.xx.xx.xx:2048 NOTE: --mute triggered...
20120603 15:43:56 23 variation(s) on previous 5 message(s) suppressed by --mute
which is saying that something is coming from 192.168.0.1 however you stated later:
Quote:
My client router local IP adress is 192.168.3.1
Which is it?
I had the same issue with losing all connection to the client after connecting to the VPN server. This was iroute issue for me. Once I added the correct iroute it worked.
Make sure you are using the exact same common-name for the filename in /tmp/openvpn/clients/ as your client's common name.