Menu
▾
▴
Re: [Openvpn-users] Problems using client-config-dir and pinging clients
|
From: Jan J. K. <ja...@ni...> - 2008-09-02 15:12:30
|
Hi NG,
NG wrote:
> Hi JJK,
>
> As always, thanks for your quick reply. The client/server pinging
> issue was resolved by switching my config to a tap interface, but then
> I ran into the problem that the client lan could not ping the server
> (the router could but the clients behind the router could not). I
> added routes indicating that 192.168.0.0 should go through the router
> to no avail. Considering it was more important for me to have the
> clients pinging the server than vice versa, I switched back to a tun
> interface.
>
>
>
>> what do you mean exactly when you say 'server is not pinging the client' ?
>> can you ping the VPN address of the client? and not the clients LAN IP? is
>> routing enabled on the client?
>>
>
> routing is enabled on the client (i have pasted the server and client
> routing tables below). What i mean is that the server can ping the
> vpn address (10.8.0.x) of the client, but not the clients lan ip
> (192.168.3.x). I have ensured that icmp packets are allowed through
> the firewall but it does not change the result.
>
one thing to check: can you ping any other IP on the client LAN, i.e.
anything but 192.168.3.1 (or whatever is the IP of your client) ?
This is a common oddity/bug to make when designing your VPN.
> ## Server Routing Table:
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 10.8.0.2 * 255.255.255.255 UH 0 0 0 tun0
> 192.168.3.0 10.8.0.2 255.255.255.0 UG 0 0
> 0 tun0 ## the client lan ip
> 192.168.2.0 10.8.0.2 255.255.255.0 UG 0 0
> 0 tun0 ## another client lan ip
> 10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
> 10.1.10.0 * 255.255.255.0 U 0 0 0 vlan1
> 192.168.0.0 * 255.255.255.0 U 0 0 0 br0
> 127.0.0.0 * 255.0.0.0 U 0 0 0 lo
> default 10.1.10.1 0.0.0.0 UG 0 0 0 vlan1
>
>
> ## Client Routing Table:
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 10.8.0.13 * 255.255.255.255 UH 0 0 0 tun0
> 192.168.3.0 * 255.255.255.0 U 0 0 0 br0
> 10.8.0.0 10.8.0.13 255.255.255.0 UG 0 0 0 tun0
> 10.1.10.0 * 255.255.255.0 U 0 0 0 vlan1
> 192.168.0.0 10.8.0.13 255.255.255.0 UG 0 0
> 0 tun0 #server lan ip
> 127.0.0.0 * 255.0.0.0 U 0 0 0 lo
> default www 0.0.0.0 UG 0 0 0 vlan1
>
> Is there something missing from my routing tables? I have not changed
> the ovpn files from my original post (with the tun interface).
>
>
>> the correct name for the 'ccd' file is indeed 'client' (case sensitive). As
>> you are using 'ccd-exclusive' you can try to connect with the 'client' ccd
>> file disabled (i.e. move it out of the way). The VPN should not be able to
>> connect, as there is no corresponding ccd file any more. If the client *can*
>> connect then there's something else wrong (server misconfig).
>>
>
> I tried this: 1)ccd-exclusive is in the server.ovpn 2)DEFAULT was
> removed 3) there was no client ccd file
>
> The result was that the client STILL connected to the vpn and did not
> list any errors indicating a ccd file could not be found. I
> understand it could be a config issue -- but I have done everything
> according to the book. My original ovpn file is in the original
> thread.
>
hmmm and if you move the DEFAULT file out of the way? does the
'ccd-exclusive' then kick in? if not then that definitely is a bug....
>
>>>>> route 192.168.2.0 255.255.255.0
>>>>> route 192.168.3.0 255.255.255.0
>>>>>
>>>>>
>>> which makes sense since I don't define a gateway in those lines -- but
>>> it is also the reason I need ccd to work so i can push specific ip
>>> addresses to each site
>>>
>>>
>> actually the route statement in the server config file are correct *without*
>> the gateway. The server 'route' statements are needed to that openvpn can
>> tell the system routing tables that openvpn will handle the routes for the
>> subnets 192.168.[23].0/24 . The corresponding gateway will be added by the
>> openvpn server software when openvpn starts.
>>
>
> I have these lines and the gw is automatically assigned as 10.8.0.2.
> Is that correct? When I used the tap interface, these lines would not
> be run after ovpn started and would not be added to the routing table.
>
this is correct when using 'tun' mode; in 'tap' mode you don't by
default do TCP/IP routing and hence there is no gw assigned automatically.
> I know I have made my situation kind of confusing. My main goal is
> that computers behind each lan are able to communicate with each
> other. The main clients are two wrt54gl routers connecting to a
> server wrt54gl router. There are some single user windows clients
> involved as well. Using the tun interface, the net30 topology is
> used, the clients all successfully ping addresses behind the server
> lan; but the server cannot ping the client lan ips. Using the tap
> interface, if ONLY the wrt54gl clients connect, everything works!
> However, once the windows clients connect, only the routers and the
> windows clients can connect but nothing behind the client lans can
> connect.
>
the tricky thing is the fact that the wrt54gl clients are already in
bridging mode and you want to add a vpn tunnel to that. It's definitely
possible but I haven't tried this myself yet. To connect a single
windows client it is definitely easier to use a routed ('tun') style
network, but....
- you need to have a proper network layout in place
- you need make sure all routes are pointing in the right direction
> Hopefully that makes sense -- any help would be appreciated in getting
> the routing completely working -- I didn't realize openvpn would
> require so much in the way of configuration and troubleshooting.
>
>
>
it's not really openvpn that is causing the problem here, but general
network design and routing. Most questions on this list (~80%) are to do
with routing, not with openvpn configuration.
cheers,
JJK
>>
>>> Thanks for all the help!
>>>
>>> NG
>>>
>>>
>>>
>>> On Sat, Aug 30, 2008 at 5:14 PM, Jan Just Keijser <ja...@ni...>
>>> wrote:
>>>
>>>
>>>> Hi NG,
>>>>
>>>> NG wrote:
>>>>
>>>>
>>>>> I am using openvpn to create a site-to-site network, with one server
>>>>> site and two client sites. I have pasted my configuration files
>>>>> below, and am using linksys routers to act as the servers and the
>>>>> clients. With my listed config, the clients successfully connect and
>>>>> are able to ping the ip addresses behind the server lan, but the
>>>>> server is not able to resolve any client ip addresses. I have fiddled
>>>>> with the routing a few times unsuccessfully. I am using the
>>>>> client-config-dir command, but it does not seem to be working, and
>>>>> there is no line in the verbose 4 log indicating that openvpn checked
>>>>> to see if a client config file existed. I am using openvpn 2.1rc7 on
>>>>> all the routers.
>>>>>
>>>>> server lan has addresses of 192.168.0.x
>>>>> client lan has addresses of 192.168.3.x
>>>>>
>>>>> server ovpn:
>>>>> server 10.9.0.0 255.255.255.0
>>>>> #tls-server
>>>>> dev tun
>>>>> tls-auth /jffs/static.key 0
>>>>> ca /jffs/ca.crt
>>>>> cert /jffs/server.crt
>>>>> key /jffs/server.key
>>>>> dh /jffs/dh1024.pem
>>>>> comp-lzo
>>>>> port 12944
>>>>> #proto udp
>>>>> verb 4
>>>>> daemon
>>>>> keepalive 10 60
>>>>> client-config-dir /jffs/ccd
>>>>> ifconfig-pool-persist /jffs/ipp.txt
>>>>> route 192.168.2.0 255.255.255.0
>>>>> route 192.168.3.0 255.255.255.0
>>>>> push "route 192.168.0.0 255.255.255.0"
>>>>> #push "route 192.168.2.0 255.255.255.0"
>>>>> #push "route 192.168.3.0 255.255.255.0"
>>>>> client-to-client
>>>>> ccd-exclusive
>>>>> #float
>>>>>
>>>>> within /jffs/ccd there are two files; default and client
>>>>>
>>>>> default:
>>>>> iroute 192.168.3.0 255.255.255.0
>>>>> route 192.168.1.0 255.255.255.0
>>>>> push "route 192.168.7.0 255.255.255.0" -- this is a made up route so I
>>>>> can test if the ccd file is working or not
>>>>>
>>>>>
>>>>>
>>>> the name of the DEFAULT file is case sensitive
>>>>
>>>>
>>>>> client:
>>>>> iroute 192.168.3.0 255.255.255.0
>>>>> push "route 192.168.6.0 255.255.255.0"
>>>>>
>>>>>
>>>>>
>>>> are you certain the certificate CN name of your client is 'client' ? you
>>>> can
>>>> verify this by doing an
>>>> openssl x509 -subject -noout -in /jffs/client.crt
>>>> Again, case-sensitive...
>>>>
>>>>
>>>>
>>>>> server routing table (after client has connected):
>>>>> Kernel IP routing table
>>>>> Destination Gateway Genmask Flags Metric Ref Use
>>>>> Iface
>>>>> 10.9.0.2 * 255.255.255.255 UH 0 0 0
>>>>> tun0
>>>>> 192.168.3.0 10.9.0.2 255.255.255.0 UG 0 0 0
>>>>> tun0
>>>>> 192.168.2.0 10.9.0.2 255.255.255.0 UG 0 0 0
>>>>> tun0
>>>>> 10.1.10.0 * 255.255.255.0 U 0 0 0
>>>>> vlan1
>>>>> 192.168.0.0 * 255.255.255.0 U 0 0 0
>>>>> br0
>>>>> 10.9.0.0 10.9.0.2 255.255.255.0 UG 0 0 0
>>>>> tun0
>>>>> 127.0.0.0 * 255.0.0.0 U 0 0 0
>>>>> lo
>>>>> default 10.1.10.1 0.0.0.0 UG 0 0 0
>>>>> vlan1
>>>>>
>>>>> @ client site
>>>>> client ovpn:
>>>>> client
>>>>> dev tun
>>>>> ns-cert-type server
>>>>> ca /jffs/ca.crt
>>>>> cert /jffs/client.crt
>>>>> key /jffs/client.key
>>>>> comp-lzo
>>>>> verb 7
>>>>> daemon
>>>>> remote xxyyzz.com
>>>>> resolv-retry infinite
>>>>> nobind
>>>>> float
>>>>> keepalive 10 60
>>>>> tls-auth /jffs/static.key 1
>>>>>
>>>>> common name for client is client
>>>>>
>>>>> client routing table:
>>>>> Kernel IP routing table
>>>>> Destination Gateway Genmask Flags Metric Ref Use
>>>>> Iface
>>>>> 10.9.0.21 * 255.255.255.255 UH 0 0 0
>>>>> tun0
>>>>> 192.168.3.0 * 255.255.255.0 U 0 0 0
>>>>> br0
>>>>> 10.1.10.0 * 255.255.255.0 U 0 0 0
>>>>> vlan1
>>>>> 192.168.0.0 10.9.0.21 255.255.255.0 UG 0 0 0
>>>>> tun0
>>>>> 10.9.0.0 10.9.0.21 255.255.255.0 UG 0 0 0
>>>>> tun0
>>>>> 127.0.0.0 * 255.0.0.0 U 0 0 0
>>>>> lo
>>>>> default www 0.0.0.0 UG 0 0 0
>>>>> vlan1
>>>>>
>>>>> None of the ccd commands show execution. Also the client can ping
>>>>> 10.9.0.1 as well as 192.168.0.1. the server can pin 10.9.0.22 but not
>>>>> 192.168.3.1
>>>>>
>>>>> Firewall scripts (identical on both sides, except for the last 3 lines
>>>>> where 192.168.x.0 represents the lan):
>>>>> iptables -I INPUT 2 -p udp --dport 12944 -j ACCEPT
>>>>> iptables -I FORWARD -i br+ -o tun+ -j ACCEPT
>>>>> iptables -I FORWARD -i tun+ -o br+ -j ACCEPT
>>>>> iptables -A INPUT -i tun+ -p icmp -j ACCEPT
>>>>> iptables -A OUTPUT -o tun+ -p icmp -j ACCEPT
>>>>> iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -o tun+ -j MASQUERADE
>>>>> iptables -A FORWARD -s 192.168.0.0/16 -o tun+ -j ACCEPT
>>>>> iptables -A FORWARD -d 192.168.0.0/16 -m state --state
>>>>> ESTABLISHED,RELATED -i tun+ -j ACCEPT
>>>>>
>>>>>
>>>>>
>>>>>
>>>> HTH,
>>>>
>>>> JJK
>>>>
>>>>
>>>>
>>>>
>>
|
