Hi everyone. First of all I'd like to thank you for your time reading this. I've got a huge problem setting up fixed IP addresses for my clients. I've seen that there's a option using ccd directory, but this is not working for me. I mean, it's totally ignored by the client who's connecting. Here's my config: [quote] port 1194 proto udp dev tun ca /usr/share/doc/openvpn/examples/easy-rsa/2.0/keys/ca.crt cert /usr/share/doc/openvpn/examples/easy-rsa/2.0/keys/server.crt key /usr/share/doc/openvpn/examples/easy-rsa/2.0/keys/server.key dh /usr/share/doc/openvpn/examples/easy-rsa/2.0/keys/dh1024.pem client-config-dir /etc/openvpn/ccd server 10.2.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt push "route 10.1.1.0 255.255.255.0" push "redirect-gateway def1" push "dhcp-option DNS 2.2.2.2" client-to-client keepalive 10 120 comp-lzo persist-key persist-tun status openvpn-status.log log /var/log/openvpn.log log-append /var/log/openvpn.log verb 3 [/quote] Some explanations: 10.1.1.0/24 is my internal_subnet (LAN clients) 10.2.0.0/24 is my openvpn_subnet (external clients) A static route is added for openvpn_subnet users to connect to internal_subnet users. THE PROBLEM: I've created user1 and a file inside: /etc/openvpn/ccd/ [quote]ls -l /etc/openvpn/ccd/ total 8 -rwxrwxrwx 1 root root 34 2011-04-04 11:01 user1[/quote] Gave all the possible permissions. Inside that file I set up a fixed IP range: [quote]cat /etc/openvpn/ccd/user1 ifconfig-push 10.2.0.50 10.2.0.50 [/quote] But, everytime user1 connects, VPN server doesn't give a ... about this ccd option and sets up a IP looking at this option: [quote] server 10.2.0.0 255.255.255.0[/quote] The only IP users are receiving is this: [quote]10.2.0.6[/quote] Here's the log: [quote]Mon Apr 4 11:13:25 2011 82.1.1.1:20898 LZO compression initialized Mon Apr 4 11:13:25 2011 82.1.1.1:20898 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ] Mon Apr 4 11:13:25 2011 82.1.1.1:20898 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ] Mon Apr 4 11:13:25 2011 82.1.1.1:20898 Local Options hash (VER=V4): '530fdded' Mon Apr 4 11:13:25 2011 82.1.1.1:20898 Expected Remote Options hash (VER=V4): '41690919' Mon Apr 4 11:13:25 2011 82.1.1.1:20898 TLS: Initial packet from 82.111.111.111:20898, sid=21b4eec3 58c53cb6 Mon Apr 4 11:13:29 2011 82.1.1.1:20898 VERIFY OK: depth=1, /C=RO/ST=RO/L=City/O=Company/OU=RO/CN=gw/emailAddress=administrator@domainexample.ro Mon Apr 4 11:13:29 2011 82.1.1.1:20898 VERIFY OK: depth=0, /C=RO/ST=RO/L=City/O=Company/OU=Company/CN=user1/emailAddress=administrator@domainexample.ro Mon Apr 4 11:13:30 2011 82.1.1.1:20898 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key Mon Apr 4 11:13:30 2011 82.1.1.1:20898 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Mon Apr 4 11:13:30 2011 82.1.1.1:20898 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key Mon Apr 4 11:13:30 2011 82.1.1.1:20898 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Mon Apr 4 11:13:31 2011 82.1.1.1:20898 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA Mon Apr 4 11:13:31 2011 82.1.1.1:20898 [user1] Peer Connection Initiated with 82.1.1.1:20898 Mon Apr 4 11:13:31 2011 user1/82.1.1.1:20898 MULTI: Learn: 10.2.0.6 -> user1/82.1.1.1:20898 Mon Apr 4 11:13:31 2011 user1/82.1.1.1:20898 MULTI: primary virtual IP for user1/82.1.1.1:20898: 10.2.0.6 Mon Apr 4 11:13:33 2011 user1/82.1.1.1:20898 PUSH: Received control message: 'PUSH_REQUEST' Mon Apr 4 11:13:33 2011 user1/82.1.1.1:20898 SENT CONTROL [user1]: 'PUSH_REPLY,route 10.1.1.0 255.255.255.0,redirect-gateway def1,dhcp-option DNS 213.154.124.1,route 10.2.0.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.2.0.6 10.2.0.5' (status=1) Mon Apr 4 11:18:01 2011 user1/82.1.1.1:20898 [user1] Inactivity timeout (--ping-restart), restarting Mon Apr 4 11:18:01 2011 user1/82.1.1.1:20898 SIGUSR1[soft,ping-restart] received, client-instance restarting[/quote] Any idea what I am missing about this? PS: Don't worry about the external IP's. Changed this only in this document. THANKS A LOT people!

Your ifconfig-push statement is causing it not to work. They need to be successive pairs using a 30 bit subnet mask, in your case the line should read: [code] ifconfig-push 10.2.0.49 10.2.0.50 [/code] Here's a more detailed explanation: http://openvpn.net/index.php/open-source/documentation/howto.html#policy

hi there, dont forget to restore ccd's permissions... michael.

Tried that. The only IP clients are receiving is 10.2.0.6 :( [quote="george"]Your ifconfig-push statement is causing it not to work. They need to be successive pairs using a 30 bit subnet mask, in your case the line should read: [code] ifconfig-push 10.2.0.49 10.2.0.50 [/code] Here's a more detailed explanation: http://openvpn.net/index.php/open-source/documentation/howto.html#policy[/quote]

Sorry, what do you mean by "restore" permissions for ccd? What permissions do you have for that folder? [quote="maikcat"]hi there, dont forget to restore ccd's permissions... michael.[/quote]

hi there, ccd files must have 644 permisions not 777.. i noticed this /C=RO/ST=RO/L=City/O=Company/OU=RO/CN=gw/emailAddress=administrator@domainexample.ro CN=gw... try rename the user1 file to gw michael

can you please try after renaming the ccd file to gw? michael.

for debugging, try adding [code]verb 5 ccd-exclusive[/code] to the server config and restart; only the client 'user1' will now be allowed to connect. Next, use the following IPs in the ccd-file [code]ifconfig-push 10.2.0.50 10.2.0.49[/code] (Note the order! the HOWTO mentions it backwards, which is wrong) In the server log you should now see that it is picking up the 'ccd' file ; if it is not, then the client is not allowed access. Once it works, remove the 'ccd-exclusive' to allow other clients to connect again.

Hah! You guys were right. Thank you so much! Restarted the server and put the /30 ranges in the ccd file and now it's working ok, but having another problem: for the 10.3.0.0/24 clients, cannot ping the LAN (10.1.1.0/24) even if the config file has the bold routes added: [quote]port 1194 proto udp dev tun ca /usr/share/doc/openvpn/examples/easy-rsa/2.0/keys/ca.crt cert /usr/share/doc/openvpn/examples/easy-rsa/2.0/keys/server.crt key /usr/share/doc/openvpn/examples/easy-rsa/2.0/keys/server.key dh /usr/share/doc/openvpn/examples/easy-rsa/2.0/keys/dh1024.pem client-config-dir /etc/openvpn/ccd server 10.2.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt push "route 10.1.1.0 255.255.255.0" [b]route 10.2.0.0 255.255.255.0 route 10.3.0.0 255.255.255.0[/b] push "redirect-gateway def1" push "dhcp-option DNS 213.154.124.1" client-to-client keepalive 10 120 comp-lzo persist-key persist-tun status openvpn-status.log log /var/log/openvpn.log log-append /var/log/openvpn.log verb 3 [/quote]

This makes sense janjust, thank you. [quote="janjust"]for debugging, try adding [code]verb 5 ccd-exclusive[/code] to the server config and restart; only the client 'user1' will now be allowed to connect. Next, use the following IPs in the ccd-file [code]ifconfig-push 10.2.0.50 10.2.0.49[/code] (Note the order! the HOWTO mentions it backwards, which is wrong) In the server log you should now see that it is picking up the 'ccd' file ; if it is not, then the client is not allowed access. Once it works, remove the 'ccd-exclusive' to allow other clients to connect again.[/quote]

Lost hope using ccd option

janjust

* check the IP address of the VPN client in the 10.0.2 range
* remove the 'ifconfig-pool-persist' line from the server config and restart the openvpn to see if it makes a difference
* run wireshark on the vpn server and do a 'ping 10.1.1.1' from the VPN client ; follow the flow of the packets and check the source and destination IPs

pwg3n

It's working now. Thanks so much.

The problem was the old IP in the server.conf (forgot to change IP, changed only the mask).

The problem was that the subnet mask was incorrect and did not match the both VPN classes.

255.255.254.0 matched both 10.0.2.0 and 10.0.3.0

The next step would be to make some iptables filters. I have to put these filters on FORWARD chain on the tun0 interface, am I right?

janjust wrote* check the IP address of the VPN client in the 10.0.2 range
* remove the 'ifconfig-pool-persist' line from the server config and restart the openvpn to see if it makes a difference
* run wireshark on the vpn server and do a 'ping 10.1.1.1' from the VPN client ; follow the flow of the packets and check the source and destination IPs

janjust

depends on what you want to filter; you're using

client-to-client

which means that all clients can see each other without passing through iptables .

To restrict access from VPN clients to hosts on your LAN use the FORWARD chain.
To restrict access from VPN clients to the VPN server itself use the INPUT chain.

pwg3n

Hm...
So i must wipe out client-to-client for the traffic to be processed by iptables?

janjust wrotedepends on what you want to filter; you're using
client-to-client
which means that all clients can see each other without passing through iptables .

To restrict access from VPN clients to hosts on your LAN use the FORWARD chain.
To restrict access from VPN clients to the VPN server itself use the INPUT chain.

pwg3n

This is a interesting one:

Excluded the client-to-client option, and tried to drop some traffic from one subnet to another:

iptables -I FORWARD 1 -i tun0 -s 10.0.3.1 -d 10.1.1.1 -j DROP

But nothing happens. Still can ping 10.1.1.1 :shock:

janjust

this is getting off-topic , as we're now talking about debugging iptables ; try inserting

iptables -I FORWARD 1 -i tun0 -s 10.0.3.1 -d 10.1.1.1 -j LOG

to see if you're actually matching the right packets.

pwg3n

Thank you janjust, you're right about the offtopic, I'll take over on my own right now.

« Previous Page