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

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.

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: [code] 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 [/code] And the clinet.ovpn is [code] 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 [/code] I use also this script for bridging: [code] ### 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 [/code]

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[quote]The ip address of openvpn server is 10.182.78.23 and the gateway 10.182.78.1[/quote] yet your server-bridge mentions 10.182.78.1 ; try changing the server-bridge line to [code]server-bridge 10.182.78.23 255.255.255.0 10.182.78.236 10.182.78.245[/code] the first IP address should always be equal to the IP of the bridge itself. finally, when using bridging you must [b]explicitly[/b] specify which 'tap' adapter you wish to use. In your case this would mean [code]dev tap0[/code]

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!

a default GW is assigned only if you use something like [code]push "redirect-gateway def1"[/code] 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.

is routing enabled on the VPN server? is there a firewall blocking things?

The server configuration: [code] 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 [/code] The client config file: [code] 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 [/code] 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

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.

no connection to subnetwork after openvpn connection

janjust

what happens if you run

tcpdump -nnel -i tap0 icmp

on the client and then ping a host on the server-side LAN? do you see ICMP replies coming back?

[deleted]

If I ping from client to an other computer in the subnetwork forexample 10.18.87.21 I get these lines on server:
12:38:45.801467 1a:e8:c8:ff:31:b8 > 00:16:3e:8a:26:fe, ethertype IPv4 (0x0800), length 98: 10.18.87.150 > 10.18.87.21: ICMP echo request, id 2328, seq 1, length 64
12:38:46.810893 1a:e8:c8:ff:31:b8 > 00:16:3e:8a:26:fe, ethertype IPv4 (0x0800), length 98: 10.18.87.150 > 10.18.87.21: ICMP echo request, id 2328, seq 2, length 64
12:38:47.815667 1a:e8:c8:ff:31:b8 > 00:16:3e:8a:26:fe, ethertype IPv4 (0x0800), length 98: 10.18.87.150 > 10.18.87.21: ICMP echo request, id 2328, seq 3, length 64

Thus:
on client:
ping -c 3 10.18.87.21
PING 10.18.87.21 (10.18.87.21) 56(84) bytes of data.

--- 10.18.87.21 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2016ms

On vpn server:
12:38:45.801467 1a:e8:c8:ff:31:b8 > 00:16:3e:8a:26:fe, ethertype IPv4 (0x0800), length 98: 10.18.87.150 > 10.18.87.21: ICMP echo request, id 2328, seq 1, length 64
12:38:46.810893 1a:e8:c8:ff:31:b8 > 00:16:3e:8a:26:fe, ethertype IPv4 (0x0800), length 98: 10.18.87.150 > 10.18.87.21: ICMP echo request, id 2328, seq 2, length 64
12:38:47.815667 1a:e8:c8:ff:31:b8 > 00:16:3e:8a:26:fe, ethertype IPv4 (0x0800), length 98: 10.18.87.150 > 10.18.87.21: ICMP echo request, id 2328, seq 3, length 64

[deleted]

on server:
tcpdump -nnel -i tap0 icmp

on client:
ping -c 3 10.18.87.23

on server:
12:47:32.325005 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 2331, seq 1, length 64
12:47:32.325045 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 2331, seq 1, length 64
12:47:33.326065 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 2331, seq 2, length 64
12:47:33.326097 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 2331, seq 2, length 64
12:47:34.327960 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 2331, seq 3, length 64
12:47:34.327997 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 2331, seq 3, length 64

[deleted]

If I run tcpdump -nnel -i tap0 icmp on the client and then I ping an machine from the vpn server I see nothing on the client.

janjust

doh, the IP addresses had me confused... looks like routing is not working the way it is supposed to be working on the server : when pinging a server-side client no replies are returned. Are the bridged interfaces in promiscuous mode (check using 'ifconfig eth0' and 'ifconfig tap0') ?

can you run 'tcpdump' on a server-side client to see if the ICMP packets are arriving there, and are replied to?

janjust

you *MAY* also be running into issues with putting a xen virtual interface into PROMISC mode, as is required for bridging. Read up on http://www.gossamer-threads.com/lists/xen/users/175478 for details on Xen+PROMISC mode.

[deleted]

on the vpn server (with ip 10.18.87.23):
ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:16:3e:a7:fc:82
inet6 addr: fe80::216:3eff:fea7:fc82/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:28117 errors:0 dropped:0 overruns:0 frame:0
TX packets:119272 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1640780 (1.5 MiB) TX bytes:36318446 (34.6 MiB)
Interrupt:246

ifconfig tap0
tap0 Link encap:Ethernet HWaddr ce:ce:9a:bb:ae:2e
inet6 addr: fe80::ccce:9aff:febb:ae2e/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:226 errors:0 dropped:0 overruns:0 frame:0
TX packets:601 errors:0 dropped:1 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:33852 (33.0 KiB) TX bytes:104374 (101.9 KiB)

I run tcpdump -nnel -i eth0 icmp on a machine in my server side with ip 10.18.87.21.
Then I ping from my client to vpn server with this command: ping -c 3 10.18.87.23.
I can ping to the server but I see nothing on the machine with ip 10.18.87.21.

janjust

I hope you also tried running

ping -c 3 10.18.87.21

also, you did verify that the server can reach the .21 machine, right :mrgreen:

[deleted]

on the vpn server with ip 10.18.87.23:
ping -c 3 10.18.87.21
PING 10.18.87.21 (10.18.87.21) 56(84) bytes of data.
64 bytes from 10.18.87.21: icmp_req=1 ttl=64 time=2.84 ms
64 bytes from 10.18.87.21: icmp_req=2 ttl=64 time=0.273 ms
64 bytes from 10.18.87.21: icmp_req=3 ttl=64 time=0.264 ms

on the client:
ping -c 3 10.18.87.21
PING 10.18.87.21 (10.18.87.21) 56(84) bytes of data.

--- 10.18.87.21 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2016ms

janjust

this is starting to look more and more like a bridging issue with your xen VM ; can you try running

tcpdump -nnel -i br0 icmp or arp

on the server bridge again, and then ping the VPN client from the LAN client. What kind of traffic is now flowing through the bridge?

is there any way you run rule out the VM?

[deleted]

It is very strange!
I run tcpdump -nnel -i br0 icmp or arp on the vpn server with ip
10.18.87.23
and ping from a lan machine with ip 10.18.87.21 to the client with ip
10.18.87.150. The lan machine with ip 10.18.87.21 can reach the clinet
with ip 10.18.87.150 and I can see the packet transfer on the server
with ip 10.18.87.23. The output on the server is:

14:19:32.500718 00:16:3e:8a:26:fe > ff:ff:ff:ff:ff:ff, ethertype ARP
(0x0806), length 42: Request who-has 10.18.87.150 tell 10.18.87.21,
length 28
14:19:32.524257 6e:6c:12:eb:be:08 > 00:16:3e:8a:26:fe, ethertype ARP
(0x0806), length 42: Reply 10.18.87.150 is-at 6e:6c:12:eb:be:08, length
28
14:19:32.524425 00:16:3e:8a:26:fe > 6e:6c:12:eb:be:08, ethertype IPv4
(0x0800), length 98: 10.18.87.21 > 10.18.87.150: ICMP echo request, id
836, seq 1, length 64
14:19:32.531571 6e:6c:12:eb:be:08 > 00:16:3e:8a:26:fe, ethertype IPv4
(0x0800), length 98: 10.18.87.150 > 10.18.87.21: ICMP echo reply, id
836, seq 1, length 64
14:19:33.498081 00:16:3e:8a:26:fe > 6e:6c:12:eb:be:08, ethertype IPv4
(0x0800), length 98: 10.18.87.21 > 10.18.87.150: ICMP echo request, id
836, seq 2, length 64
14:19:33.549785 6e:6c:12:eb:be:08 > 00:16:3e:8a:26:fe, ethertype IPv4
(0x0800), length 98: 10.18.87.150 > 10.18.87.21: ICMP echo reply, id
836, seq 2, length 64
14:19:34.499239 00:16:3e:8a:26:fe > 6e:6c:12:eb:be:08, ethertype IPv4
(0x0800), length 98: 10.18.87.21 > 10.18.87.150: ICMP echo request, id
836, seq 3, length 64
14:19:34.568939 6e:6c:12:eb:be:08 > 00:16:3e:8a:26:fe, ethertype IPv4
(0x0800), length 98: 10.18.87.150 > 10.18.87.21: ICMP echo reply, id
836, seq 3, length 64
14:19:37.504523 00:0c:f6:89:d4:08 > 00:16:3e:a7:fc:82, ethertype ARP
(0x0806), length 60: Request who-has 10.18.87.23 tell 10.18.87.100,
length 46
14:19:37.504554 00:16:3e:a7:fc:82 > 00:0c:f6:89:d4:08, ethertype ARP
(0x0806), length 42: Reply 10.182.78.23 is-at 00:16:3e:a7:fc:82, length
28
14:19:37.522827 6e:6c:12:eb:be:08 > 00:16:3e:8a:26:fe, ethertype ARP
(0x0806), length 42: Request who-has 10.18.87.21 tell 10.18.87.150,
length 28
14:19:37.522995 00:16:3e:8a:26:fe > 6e:6c:12:eb:be:08, ethertype ARP
(0x0806), length 42: Reply 10.18.87.21 is-at 00:16:3e:8a:26:fe, length
28

janjust

so it works one way?
please check that the MAC address of the VPN adapter on the client is indeed '6e:6c:12:eb:be:08'.

[deleted]

yes it works one way.

on the client:
ifconfig tap0
tap0 Link encap:Ethernet HWaddr 6e:6c:12:eb:be:08
inet addr:10.18.87.150 Bcast:10.18.87.255 Mask:255.255.255.0
inet6 addr: fe80::6c6c:12ff:feeb:be08/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:66 errors:0 dropped:0 overruns:0 frame:0
TX packets:46 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:11608 (11.3 KiB) TX bytes:7298 (7.1 KiB)

[deleted]

@janjust
This is the content of interfaces file of the client:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

Is it possible that the problem is caused by the client?

janjust

now try the reverse using the same 'tcpdump' command.
it might (temporarily) work.

this sounds like a bridging issue in combination with a virtual host, not a client side issue.

[deleted]

OK.
On the vpn server with ip 10.18.87.23
tcpdump -nnel -i br0 icmp or arp

on the client:
ping -c 2 10.18.87.21
PING 10.18.87.21 (10.18.87.21) 56(84) bytes of data.

--- 10.18.87.21 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1007ms

on vpn server with ip 10.18.87.23:
16:25:19.174341 00:1e:e5:84:fa:cd > 00:16:3e:a7:fc:82, ethertype ARP (0x0806), length 60: Request who-has 10.18.87.23 tell 10.18.87.1, length 46
16:25:19.174363 00:16:3e:a7:fc:82 > 00:1e:e5:84:fa:cd, ethertype ARP (0x0806), length 42: Reply 10.18.87.23 is-at 00:16:3e:a7:fc:82, length 28
16:25:28.647271 4e:78:cf:c8:fe:da > 00:16:3e:8a:26:fe, ethertype IPv4 (0x0800), length 98: 10.18.87.150 > 10.18.87.21: ICMP echo request, id 2577, seq 1, length 64
16:25:29.654447 4e:78:cf:c8:fe:da > 00:16:3e:8a:26:fe, ethertype IPv4 (0x0800), length 98: 10.18.87.150 > 10.18.87.21: ICMP echo request, id 2577, seq 2, length 64
16:25:33.642187 4e:78:cf:c8:fe:da > 00:16:3e:8a:26:fe, ethertype ARP (0x0806), length 42: Request who-has 10.18.87.21 tell 10.18.87.150, length 28
16:25:33.642365 00:16:3e:8a:26:fe > 4e:78:cf:c8:fe:da, ethertype ARP (0x0806), length 42: Reply 10.18.87.21 is-at 00:16:3e:8a:26:fe, length 28

Attention: I started a new vpn session and the client has now an other mac address

I post in the next reply the bridge script of the vpn server

[deleted]

#!/bin/bash

#################################
# Set up Ethernet bridge on Linux
# Requires: bridge-utils
#################################

# 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.18.87.23"
eth_netmask="255.255.255.0"
eth_broadcast="10.18.87.255"

for t in $tap; do
openvpn --mktun --dev $t
done

brctl addbr $br
brctl addif $br $eth

for t in $tap; do
brctl addif $br $t
done

for t in $tap; do
ifconfig $t 0.0.0.0 promisc up
done

ifconfig $eth 0.0.0.0 promisc up

ifconfig $br $eth_ip netmask $eth_netmask broadcast $eth_broadcast

janjust

that's very standard - the problem is not the bridge inside the VM, it's how the bridge talks to the host OS ... how is networking configured on the dom0/host OS?

[deleted]

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo br0
iface lo inet loopback

# The primary network interface
iface eth0 inet manual

iface br0 inet static
bridge_ports eth0
address 10.18.87.23
gateway 10.18.87.1
netmask 255.255.255.0
broadcast 10.18.87.255

janjust

that's the config of the VPN server itself, right, which you stated is a VM:

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

this xen VM is running on a xen host (dom0); what is the network configuration of THAT machine.

« Previous Page Next Page »