[SOLVED] Can connect via OpenVPN from Android but I ...

[BobAGI]

This is my 3rd thread here about my OpenVPN setup problems.
The others are here:
1) OpenVPN server only connects local clients
2) How to copy OpenVPN Connect logfiles?

I want to summarize the state I am in right now:
- My OpenVPN server is installed on a Raspberry Pi running the Raspbmc distribution
- It is clearly not completely configured (see below) after mixing several tutorials and forum advice posts
- I can connect just fine using my Android OpenVPN Connect app (both from the mobile network and from a WiFi network)
- While I am connected I can FTP to my server (the Raspberry Pi) using an Android FTP client and the local address 192.168.0.150
- But I cannot reach my local FTP server or the Internet

I have followed a few tutorials on setting up the OpenVPN server and got to a situation where I could connect but then do basically nothing...

File edits:
I have the following in my server.conf file:

Code: Select all

local 192.168.0.150
dev tun
proto udp
port 1194
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/BBOpenVPN.crt
key /etc/openvpn/easy-rsa/keys/BBOpenVPN.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
server 10.8.0.0 255.255.255.0
#ifconfig 10.8.0.1 10.8.0.2
push "route 10.8.0.1 255.255.255.255"
push "route 10.8.0.0 255.255.255.0"
push "route 192.168.0.0 255.255.255.0"
push "dhcp-option DNS 192.168.0.129"
push "redirect-gateway def1"
#client-to-client
duplicate-cn
keepalive 10 120
tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0
cipher AES-128-CBC
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn-status.log 20
log /var/log/openvpn.log
verb 4

Additionally there is a file /etc/network/if-up.d/secure-rmc where this distribution seems to keep its iptables commands.
Here I have the following:

Code: Select all

    iptables -A INPUT -s $NETMASK -i $IFACE -j ACCEPT
    iptables -t nat -A INPUT -i eth0 -p udp -m udp --dport 1194 -j ACCEPT
    iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
    #iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j SNAT --to-source 192.168.0.150
    iptables -I INPUT -p udp -m udp --dport 1194 -j ACCEPT
    iptables -A INPUT -i $IFACE -j DROP

Note that I don't have any idea what these lines actually do, but they were put there on advice from forum members and a couple were added from a tutorial, which had put them into the file /etc/network/interfaces, which does not exist in the raspbmc distribution...

Finally /etc/sysctl.conf contains this:

Code: Select all

net.ipv4.ip_forward=1
vm.panic_on_oom = 0
vm.dirty_expire_centisecs = 1000
vm.dirty_writeback_centisecs = 1500
kernel.random.write_wakeup_threshold=128
kernel.random.read_wakeup_threshold=32
kernel.random.poolsize=512
kernel.random.entropy_avail=4096
vm.min_free_kbytes=16384
vm.swappiness=10

Where the important change I did was to un-comment the first line.

If I can't get this running soon I think I have to switch to a different solution like using DD-WRT on a compatible router.

In fact today I bought a D-Link DIR-615 (which is compatible with DD-WRT) only to find that its Ethernet ports were broken.
So I have to get a replacement tomorrow.

DD-WRT firmware for the routers contain both a PPTP and an OpenVPN server ready to be configured through a web interface.
Seems much easier to do, but it has one drawback and that is that I have to replace my existing router if I want to get access to my NAS.
The existing router is much newer than the 615 and has a gigabit Ethernet connection, which I would rather keep.
So I really want to keep the Pi as the server.

[BobAGI]

UPDATE
It turned out that the iptables on my Pi were not properly set up.
In fact after every reboot the iptables list command returned a completely empty content!!!
The only way I have found so far to fix this is to manually log on with PuTTY and enter the following command on the command line:

Code: Select all

sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j SNAT --to-source 192.168.0.150

After this the routing through the Pi to the local network and out to the Internet starts working as it should.

The problem is that so far I have found no way to get the entry into iptables automatically on startup.
The command IS in /etc/rc.local and also in another file /etc/network/if-up.d/secure-rmc, which is specific to the RASPBMC distribution on the Pi. But still on reboot the iptables lists as empty...

The strange thing is that on my PPTP VPN server (also installed on the Pi) the routing works just fine even with these iptables entries missing. But on the PPTP server the clients get assigned IP addresses out of a pool within the local subnet, so I guess there is no need for further routing in that case?

QUESTION:
Can I change the OpenVPN assignment rule concerning VPN client addresses so it to hands out local addresses in a range not overlapping DHCP or the PPTP ranges?
Would that help to make the browsing work?

[BobAGI]

Today I have found out that the problem seems to be caused by some process that is started on the Pi after the regular boot-up.
In fact I was able to connect an OpenVPN client and then use resources on the local network if I was quick enough after initiating the reboot of the Pi.
What happens next is that some 30-60 seconds later there is something else that is starting and it erases the iptables content and at this time the connectivity of my guest disappears.

I can only guess that some service or other (XBMC maybe) on its startup ERASES iptables if it discovers a setting that disables the firewall....

If I enter the single iptables command after this has happened then connectivity is restored.

So either I am able to find the file that holds the iptables commands for the firewall so I can add the needed OpenVPN entry there and then enable the firewall in the RASPMMC settings or else I have to set up a cron job that runs say every 3 minutes and enters this command if a specific file exists, which I have to create as part of runlevel 2 startup. Of course the file must be erased after it is detected.
The latter solution sounds really like a cludge to me.

In any case it seems like this is no longer an OpenVPN issue.