[deleted]
Hi,
I can connect from a windows 7 machine to my openvpn server with a new assigned ip address.
But I can not connect machines in my private network. A ping try to any network component results to "Destination host unreachable"
I disabled the firewall on windows but it did not solve the problem.
Any idea what the problem is?
Thanks
janjust
please post your client+server config files , plus , give is a hint to which hosts you are trying to reach on which end of the VPN tunnel.
[deleted]
The openvpn server is a debian squeeze virtual machine (KVM). I use bridge connection.
The ip address of openvpn server is 10.182.78.23 and the gateway 10.182.78.1
server.conf:
port 4891
proto tcp
dev tap
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/openvpnserver.crt
key /etc/openvpn/easy-rsa/keys/openvpnserver.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
ifconfig-pool-persist ipp.txt
server-bridge 10.182.78.1 255.255.255.0 10.182.78.236 10.182.78.245
push "route 10.182.78.0 255.255.255.0"
keepalive 10 120
comp-lzo
persist-key
persist-tun
status /var/log/openvpn-status.log
verb 3
And the clinet.ovpn is
client
dev tap
proto tcp
remote me.homelinux.com 4891
resolv-retry infinite
nobind
pkcs12 me.p12
ns-cert-type server
comp-lzo
verb 3
I use also this script for bridging:
### BEGIN INIT INFO
# Provides: bridge
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start daemon at boot time
# Description: Enable service provided by daemon.
### END INIT INFO
#!/bin/bash
# Create global variables
# Define Bridge Interface
br="br0"
# Define list of TAP interfaces to be bridged,
# for example tap="tap0 tap1 tap2".
tap="tap0"
# Define physical ethernet interface to be bridged
# with TAP interface(s) above.
eth="eth0"
eth_ip="10.182.78.23"
eth_netmask="255.255.255.0"
eth_broadcast="10.182.78.255"
gw="10.182.78.1"
start_bridge () {
#################################
# Set up Ethernet bridge on Linux
# Requires: bridge-utils
#################################
for t in $tap; do
openvpn --mktun --dev $t
done
for t in $tap; do
ifconfig $t 0.0.0.0 promisc up
done
ifconfig $eth 0.0.0.0 promisc up
brctl addbr $br
brctl addif $br $eth
for t in $tap; do
brctl addif $br $t
done
ifconfig $br $eth_ip netmask $eth_netmask broadcast $eth_broadcast up
route add default gw $gw $br
}
stop_bridge () {
####################################
# Tear Down Ethernet bridge on Linux
####################################
ifconfig $br down
brctl delbr $br
for t in $tap; do
openvpn --rmtun --dev $t
done
ifconfig $eth $eth_ip netmask $eth_netmask broadcast $eth_broadcast up
route add default gw $gw $eth
}
case "$1" in
start)
echo -n "Starting Bridge"
start_bridge
;;
stop)
echo -n "Stopping Bridge"
stop_bridge
;;
restart)
stop_bridge
sleep 2
start_bridge
;;
*)
echo "Usage: $0 {start|stop|restart}" >&2
exit 1
;;
esac
janjust
first of all, ask yourself if you really need bridging. Bridging is only required for forwarding broadcast and non-IP based traffic. If neither are required then you're better off without bridging.
Second, you wrote
The ip address of openvpn server is 10.182.78.23 and the gateway 10.182.78.1
yet your server-bridge mentions 10.182.78.1 ; try changing the server-bridge line to
server-bridge 10.182.78.23 255.255.255.0 10.182.78.236 10.182.78.245
the first IP address should always be equal to the IP of the bridge itself.
finally, when using bridging you must
explicitly specify which 'tap' adapter you wish to use. In your case this would mean
dev tap0
[deleted]
janjust, thank you! Your instructions helped me.
I had earlier changed those parameters but not at the same time. What I do not understand yet, is that the windows client dose not still have a default gateway. An ipconifg in windows results to:
....
IPv4 Address.................. : 10.182.78.236
Subnet mask.................. : 255.255.255.0
Default Gateway............. :
I chose for bridging because I need an ip address of my private network to reach other components in the network. I read somewhere without bridging I do not get an ip address from the openvpn. If I am wrong could you explain me what I can do with tunneling, please.
Nogmaals bedankt!
janjust
a default GW is assigned only if you use something like
push "redirect-gateway def1"
on the server; otherwise the tap-win32 adapter is not assigned a GW address; routing to the 10.182.78.0/24 network will still work, however.
[deleted]
Thank you!
[deleted]
Hello,
the same problem appears again on my vpn server, a xen VM.
I can connect to the server but can not connect to the subnetwork.
All before mentionned issues are now correct.
Any ideas?!
Deb
janjust
is routing enabled on the VPN server? is there a firewall blocking things?
[deleted]
The server configuration:
port 1194
proto tcp
dev tap0
ca keys/ca.crt
cert keys/openvpnServer.crt
key keys/openvpnServer.key
dh keys/dh1024.pem
ifconfig-pool-persist ipp.txt
server-bridge 10.18.87.23 255.255.255.0 10.18.87.150 10.18.87.155
push "route 10.18.87.0 255.255.255.0"
status openvpn-status.log
verb 3
The client config file:
client
dev tap0
porto tcp
remote me.homelinux.com 1194
resolv-retry-infinite
nobind
ca keys/ca.crt
cert keys/client.crt
key keys/client.key
ns-cert-type server
comp-lzo
verb 3
The firewall allows access:
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
Mimiko
deb, you don't need to push the server's bridge IP mask: push "route 10.18.87.0 255.255.255.0".
The routes are added automatically, when client gets the IP for tap-adapter.
[deleted]
@Mimiko: thank you for the reply!
I commented out push "route ...", but no result!
janjust
is routing enabled
cat /proc/sys/net/ipv4/ip_forward
?
is the bridge operational?
brctl show br0
if so, then try using 'tcpdump' or 'wireshark' to troubleshoot:
* run 'tcpdump -nnel --i br0'
* now try to ping a host on the server-side subnet from the VPN client; what kind of traffic shows up in the tcpdump window?
[deleted]
@janjust: Thank you!
cat /proc/sys/net/ipv4/ip_forward
1
brctl show br0
bridge name bridge id STP enabled interfaces
br0 8000.00163ea7fc82 no eth0
tap0
tcpdump -nnel --i br0
tcpdump version 4.1.1
libpcap version 1.1.1
Usage: tcpdump [-aAbdDefIKlLnNOpqRStuUvxX] [ -B size ] [ -c count ]
[ -C file_size ] [ -E algo:secret ] [ -F file ] [ -G seconds ]
[ -i interface ] [ -M secret ] [ -r file ]
[ -s snaplen ] [ -T type ] [ -w file ] [ -W filecount ]
[ -y datalinktype ] [ -z command ] [ -Z user ]
[ expression ]
tcpdump -nnel -i br0
10:36:59.253891 00:0c:f6:89:d4:08 > 00:16:3e:a7:fc:82, ethertype IPv4 (0x0800), length 66: 10.18.87.100.54905 > 10.18.87.23.22: Flags [.], ack 1293440, win 6157, options [nop,nop,TS val 2603141 ecr 252826], length 0
....
5389 packets captured
5392 packets received by filter
0 packets dropped by kernel
janjust
the tcpdump output suggests that there are NO ICMP packets at all? that is strange; what happens if you ping the VPN server IP from the VPN client? does that work?
[deleted]
From client:
ping -c 3 10.18.87.23
PING 10.18.87.23 (10.18.87.23) 56(84) bytes of data.
64 bytes from 10.18.87.23: icmp_req=1 ttl=64 time=8.061 ms
64 bytes from 10.18.87.23: icmp_req=2 ttl=64 time=2.041 ms
64 bytes from 10.18.87.23: icmp_req=3 ttl=64 time=2.042 ms
--- 10.18.87.23 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 2.041/4.048/8.061/2.009 ms
janjust
OK, so that works; I would have expected to see something appear in the tcpdump output (if you ran 'tcpdump' in the background) but perhaps I'm confused about tap/bridging mode.
Now run 'tcpdump -nnel -i br0 icmp or arp' and ping a host on the subnet from the client - do you see any traffic?
[deleted]
on the vpn server:
tcpdump -nnel -i br0 icmp
on the client:
ping -c 3 10.18.87.23
on the vpn server:
12:22:20.860166 1a:e8:c8:ff:31:b8 > 00:16:3e:a7:fc:82, ethertype IPv4 (0x0800), length 98: 10.18.87.150 > 10.18.87.23: ICMP echo request, id 2291, seq 1, length 64
12:22:20.860213 00:16:3e:a7:fc:82 > 1a:e8:c8:ff:31:b8, ethertype IPv4 (0x0800), length 98: 10.18.87.23 > 10.18.87.150: ICMP echo reply, id 2291, seq 1, length 64
12:22:21.858112 1a:e8:c8:ff:31:b8 > 00:16:3e:a7:fc:82, ethertype IPv4 (0x0800), length 98: 10.18.87.150 > 10.18.87.23: ICMP echo request, id 2291, seq 2, length 64
12:22:21.858138 00:16:3e:a7:fc:82 > 1a:e8:c8:ff:31:b8, ethertype IPv4 (0x0800), length 98: 10.18.87.23 > 10.18.87.150: ICMP echo reply, id 2291, seq 2, length 64
12:22:22.859998 1a:e8:c8:ff:31:b8 > 00:16:3e:a7:fc:82, ethertype IPv4 (0x0800), length 98: 10.18.87.150 > 10.18.87.23: ICMP echo request, id 2291, seq 3, length 64
12:22:22.860024 00:16:3e:a7:fc:82 > 1a:e8:c8:ff:31:b8, ethertype IPv4 (0x0800), length 98: 10.18.87.23 > 10.18.87.150: ICMP echo reply, id 2291, seq 3, length 64
janjust
looks like the VPN bridge is doing what it is supposed to be doing - I see ICMP requests and replies flying back and forth. Check for firewalls on the client side to see if they're blocking inbound traffic on the tun/tap-win32 adapter
[deleted]
on client:
iptables -L
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
I use command line vpn clinet on the client side. Clinet is also a debian squeeze.
