Menu
▾
▴
Re: [Openvpn-users] Problems using client-config-dir and pinging clients
|
From: NG <cra...@gm...> - 2008-09-03 01:21:06
|
Hi JJK,
On Tue, Sep 2, 2008 at 11:12 AM, Jan Just Keijser <ja...@ni...> wrote:
> 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.
I made sure to check this, and that is what I meant by 192.168.3.x. No
ip addresses inthat range are ping-able. Additionally, I made sure
that icmp packets would work (and when client pinging does work -- in
tap mode with only routers connecting to each other -- 192.168.3.1
does ping properly)
>
>> ## 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....
I am using 2.1rc7 -- the latest version compiled with this firmware.
If I move DEFAULT out of the way, I still connect. The only time it
prevents me from connecting is if I point to an invalid directory. Is
this a "reported" bug? I've tried changing the common name to a FQDN
(test.test.local) and that did not work, I tried using ccd files that
were all caps and all lower caps and that didn't work either.
>
>>
>>>>>>
>>>>>> 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.
Ok, is there any way to indicate these routes in the main server
config without knowing which client gets which ip? Or can the clients
push their route to the server in some way?
>>
>> 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
The part I don't understand is why the pinging works one way and not
the other; do you notice any errors in my routing tables that are
preventing that from happening? I believe my network layout is
properly done; is there a way for me to show you to confirm?
>>
>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
|