Hi everybody, I got the follwoing problem: Goal: Client T (Ubuntu 12.04) behind a router (FritzBox) net 192.168.2.0 wants to reach Server H (192.168.16.1) net 192.168.16.0 also behind a router (FritzBox). H is reachable by dynamic DNS. Problem: I am using certificates and I can connect without a problem but I cannot ping any pc in 192.168.16.0 from Client T. Internal ping in 192.168.16.0 works great. PPTP works fine with the same configuration. My configuration: Openvpn Server 192.168.16.116 server.conf: [quote]port 1194 proto udp dev tun ca ./easy-rsa2/keys/ca.crt cert ./easy-rsa2/keys/server.crt dh ./easy-rsa2/keys/dh1024.pem server 10.8.0.0 255.255.255.0 push "route 192.168.16.0 255.255.255.0" push "dhcp-option DNS 208.67.222.222" push "dhcp-option DNS 208.67.220.220" keepalive 10 120 persist-key persist-tun status openvpn-status.log verb 3 [/quote] ifconfig while connected with openvpn: [quote]eth0 Link encap:Ethernet HWaddr b8:27:eb:62:78:9d inet addr:192.168.16.116 Bcast:192.168.16.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5230404 errors:0 dropped:0 overruns:0 frame:0 TX packets:4978396 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1754096872 (1.6 GiB) TX bytes:1845003236 (1.7 GiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:29 errors:0 dropped:0 overruns:0 frame:0 TX packets:29 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:2447 (2.3 KiB) TX bytes:2447 (2.3 KiB) tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.8.0.1 P-t-P:10.8.0.2 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) [/quote] client: [quote]client dev tun proto udp mydomain.com 1194 resolv-retry infinite nobind persist-key persist-tun ca ca.crt cert client.crt key client.key ns-cert-type server comp-lzo verb 3 [/quote] ifconfig client while connected with openvpn: [quote]eth0 Link encap:Ethernet HWaddr 00:1b:24:e7:21:39 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:4989 errors:0 dropped:0 overruns:0 frame:0 TX packets:4989 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:441557 (441.5 KB) TX bytes:441557 (441.5 KB) tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.8.0.6 P-t-P:10.8.0.5 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:2 overruns:0 frame:0 TX packets:16 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 B) TX bytes:897 (897.0 B) wlan0 Link encap:Ethernet HWaddr 00:1c:bf:4e:e0:d0 inet addr:192.168.2.37 Bcast:192.168.2.255 Mask:255.255.255.0 inet6 addr: fe80::21c:bfff:fe4e:e0d0/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1072975 errors:0 dropped:0 overruns:0 frame:0 TX packets:1118478 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:496478144 (496.4 MB) TX bytes:164918319 (164.9 MB)[/quote] net.ipv4.ip_forward=1 in sysctl.conf is activated. Port 1194 UDP is open IP Routing in the router is 10.8.0.0, 255.255.255.0, 192.168.16.116. Routers IP is 192.168.16.100. Anybody have any idea what I have done wrong? Thank you for some help Tom

At first glance there are no rules really blocking this traffic. And the client appears not to have a firewall in place. Can you give the output of: [code]iptables-save[/code] to list the interfaces? and [code]netstat -rn[/code] to show the routes? And a second question: Are you familiair with tcpdump? Using [code]tcpdump -n -i tun0[/code] you could be able to see if packets are really travelling on the tunnel, if you run a ping at the same time.

Run the tcpdump on the server, as the client does not have any firewall in place, as it looks like right now. You should be able to see packets arriving at the interface, but no ICMP-Reply returning. Just as a check, you can try to run without any iptables-rules in place on the server, by running [code]iptables -F iptables -X[/code] The other thing i noticed was this: [quote][code]-A POSTROUTING -s 192.0.0.0/8 ! -d 192.0.0.0/8 -o eth0 -j MASQUERADE[/code][/quote] This netblock is far too big, you should use something like [code]-A POSTROUTING -s 192.168.0.0/16 ! -d 192.168.0.0/16 -o eth0 -j MASQUERADE[/code]

[quote]Can you use ssh directly to the machine[/quote] I guess the next time I should start thinking...thanks for the hint.. :roll: Alright, I connected on another machine to the server via ssh to make sure that the session stays alive, then: [code]tcpdump -n -i tun0[/code] I connected from the client via Openvpn and tried to ping the server. No results at all. I also tried without iptables, but again no response. I am really stuck now.

Connection Problems behind a router

tomnick

Hi everybody,

I got the follwoing problem:

Goal:

Client T (Ubuntu 12.04) behind a router (FritzBox) net 192.168.2.0 wants to reach Server H (192.168.16.1) net 192.168.16.0 also behind a router (FritzBox). H is reachable by dynamic DNS.

Problem:

I am using certificates and I can connect without a problem but I cannot ping any pc in 192.168.16.0 from Client T. Internal ping in 192.168.16.0 works great. PPTP works fine with the same configuration.

My configuration:

Openvpn Server 192.168.16.116

server.conf:

port 1194
proto udp
dev tun
ca ./easy-rsa2/keys/ca.crt
cert ./easy-rsa2/keys/server.crt
dh ./easy-rsa2/keys/dh1024.pem
server 10.8.0.0 255.255.255.0
push "route 192.168.16.0 255.255.255.0"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
keepalive 10 120
persist-key
persist-tun
status openvpn-status.log
verb 3

ifconfig while connected with openvpn:

eth0 Link encap:Ethernet HWaddr b8:27:eb:62:78:9d
inet addr:192.168.16.116 Bcast:192.168.16.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5230404 errors:0 dropped:0 overruns:0 frame:0
TX packets:4978396 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1754096872 (1.6 GiB) TX bytes:1845003236 (1.7 GiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:29 errors:0 dropped:0 overruns:0 frame:0
TX packets:29 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2447 (2.3 KiB) TX bytes:2447 (2.3 KiB)

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.8.0.1 P-t-P:10.8.0.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

client:

client
dev tun
proto udp
mydomain.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
ns-cert-type server
comp-lzo
verb 3

ifconfig client while connected with openvpn:

eth0 Link encap:Ethernet HWaddr 00:1b:24:e7:21:39
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:4989 errors:0 dropped:0 overruns:0 frame:0
TX packets:4989 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:441557 (441.5 KB) TX bytes:441557 (441.5 KB)

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.8.0.6 P-t-P:10.8.0.5 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:2 overruns:0 frame:0
TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:897 (897.0 B)

wlan0 Link encap:Ethernet HWaddr 00:1c:bf:4e:e0:d0
inet addr:192.168.2.37 Bcast:192.168.2.255 Mask:255.255.255.0
inet6 addr: fe80::21c:bfff:fe4e:e0d0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1072975 errors:0 dropped:0 overruns:0 frame:0
TX packets:1118478 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:496478144 (496.4 MB) TX bytes:164918319 (164.9 MB)

net.ipv4.ip_forward=1 in sysctl.conf is activated. Port 1194 UDP is open IP Routing in the router is 10.8.0.0, 255.255.255.0, 192.168.16.116. Routers IP is 192.168.16.100. Anybody have any idea what I have done wrong? Thank you for some help

Tom

mwandelaar

After making a drawing of your network-setup, some things came to my mind:

First: Client T is Ubuntu. I've had several issues with Firestarter (Firewall on Ubuntu) default blocking any tun-interface. Please check is this is the issue first.
Second:
- Can you ping the local vpn-address on the client? (10.8.0.6)
- Can you ping the vpn-server on it's vpn-address? (10.8.0.5)
- Can you ping the vpn-server on it's LAN-address? (192.168.16.116)
- Can you ping the remote router on the LAN-address? (192.168.16.100)
All from Client T.

I guess the last (or the last 2) will fail, according to the original problem. Depending on your results, we can figure-out where the packets got lost.

tomnick

- Can you ping the local vpn-address on the client? (10.8.0.6)
- Can you ping the vpn-server on it's vpn-address? (10.8.0.5)
- Can you ping the vpn-server on it's LAN-address? (192.168.16.116)
- Can you ping the remote router on the LAN-address? (192.168.16.100)

-yes
-no
-no
-no

Could not find anything on the first issue....

mwandelaar

This actually means that the ping packets are dropped on the server-side of the tunnel.
The most likely cause of this is a firewall-issue on the vpn-server. Probably the firewall-policy is very tight and drops everything from the tun-interface.

Can you review the firewall-rules there?
And maybe post the output from

iptables -L -n

here?

tomnick

iptables -L -n Client:

Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

iptables -L -n VPN Server:

Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state NEW

Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state NEW
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state NEW
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state NEW

mwandelaar

At first glance there are no rules really blocking this traffic. And the client appears not to have a firewall in place.
Can you give the output of:

iptables-save

to list the interfaces?
and

netstat -rn

to show the routes?

And a second question: Are you familiair with tcpdump? Using

tcpdump -n -i tun0

you could be able to see if packets are really travelling on the tunnel, if you run a ping at the same time.

tomnick

iptables-save on Openvpn Server:

*filter
:INPUT ACCEPT [3465213:409998513]
:FORWARD ACCEPT [5626911:1858128569]
:OUTPUT ACCEPT [3126632:1708369322]
-A INPUT -i tun0 -m state --state NEW -j ACCEPT
-A FORWARD -i tun0 -o eth0 -m state --state NEW -j ACCEPT
-A FORWARD -i eth0 -o tun0 -m state --state NEW -j ACCEPT
-A FORWARD -i tun0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i tun0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o tun0 -m state --state NEW -j ACCEPT
COMMIT
# Completed on Sun Aug 18 10:35:30 2013
# Generated by iptables-save v1.4.14 on Sun Aug 18 10:35:30 2013
*nat
:PREROUTING ACCEPT [146091:9832055]
:INPUT ACCEPT [117884:7971111]
:OUTPUT ACCEPT [7347:558985]
:POSTROUTING ACCEPT [14555:926787]
-A POSTROUTING -s 192.0.0.0/8 ! -d 192.0.0.0/8 -o eth0 -j MASQUERADE
COMMIT

netstat -rn on openvpn Server

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.16.100  0.0.0.0         UG        0 0          0 eth0
10.8.0.0        10.8.0.2        255.255.255.0   UG        0 0          0 tun0
10.8.0.2        0.0.0.0         255.255.255.255 UH        0 0          0 tun0
192.168.16.0    0.0.0.0         255.255.255.0   U         0 0          0 eth0
192.168.16.234  0.0.0.0         255.255.255.255 UH        0 0          0 ppp0

tcpdump -n -i tun0

Running where? Server or Client?

Thanks you so much mwandelaar that you are helping me out so hard...

mwandelaar

Run the tcpdump on the server, as the client does not have any firewall in place, as it looks like right now.
You should be able to see packets arriving at the interface, but no ICMP-Reply returning.
Just as a check, you can try to run without any iptables-rules in place on the server, by running

iptables -F
iptables -X

The other thing i noticed was this:

-A POSTROUTING -s 192.0.0.0/8 ! -d 192.0.0.0/8 -o eth0 -j MASQUERADE

This netblock is far too big, you should use something like

-A POSTROUTING -s 192.168.0.0/16 ! -d 192.168.0.0/16 -o eth0 -j MASQUERADE

tomnick

Ok, the problem is, I am sitting at the client and not able to connect the server via Openvpn (the whole problem here) but with pptp. So everything I am doing on the VPN server need me to dial in via pptp. Running the tcpdump on the server means I need to get in via pptp but then I am not connected with Openvpn so that I cannot get the right ping results at the client. Same with iptables -F and -X.

mwandelaar

Can you use ssh directly to the machine?
An ssh-session should keep alive when connecting the VPN.
To be really sure, don't redirect any gateway when testing, that way the ssh-session definetly stays alive.

tomnick

Can you use ssh directly to the machine

I guess the next time I should start thinking...thanks for the hint.. :roll:

Alright, I connected on another machine to the server via ssh to make sure that the session stays alive, then:

tcpdump -n -i tun0

I connected from the client via Openvpn and tried to ping the server. No results at all. I also tried without iptables, but again no response. I am really stuck now.

tomnick

Well another thing I just found out is, that, when I am connected to OpenVPN, I can access my router via https//myrouter.etc. I am no able to reach any service or even use my browser while I am connectet via Openvpn but the router...

mwandelaar

Did you enable ip-forwarding?
You can check for it with the following command:

sysctl net.ipv4.ip_forward

It should return 1. If it says 0 you can enable it with (as root)

sysctl net.ipv4.ip_forward=1

and modify /etc/sysctl.conf to make it persistent after a reboot.

tomnick

Yes I did, here is the output:

root@raspberrypi:~# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

tomnick

Problem solved!!!

In client.conf the word "remote" was missing...what a pain in the....mwandelaar thank you so much for your help...guys like you keep things up and I really appreciate you patience....