kurt2439
Briefly, I can connect to the OpenVPN server with my current setup and am using bridging. I can ping the OpenVPN internal IP, and my assigned IP from the OpenVPN server. I cannot ping any of the other hosts on that LAN from my client. The OpenVPN server can ping all hosts on LAN.
iptables is OFF on both client and server
I enabled ip_forward on the server, though I'm not sure this is necessary when using bridging.
I've been trying to figure out what is going on, but I can't determine why I can't ping the other hosts. I'll provide my routing info below. I think everything else is very stock in terms of the server.conf and client.conf. I'm not pushing any rules, the only real edit being "bridge-server 192.168.1.92 255.255.255.0 192.168.1.18 192.168.1.20"
the "bridge-start" script seems to have all the correct values. I did have to re-add the default route on the OpenVPN server after it was first setup.
route on server:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 * 255.255.255.0 U 0 0 0 br0
default 192.168.1.1 0.0.0.0 UG 0 0 0 br0
route on client:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 * 255.255.255.0 U 0 0 0 tap0
192.168.10.0 * 255.255.255.0 U 2 0 0 eth1
default Wireless_Broadb 0.0.0.0 UG 0 0 0 eth1
maikcat
can you please post:
the server config
the output of ifconfig command on server
the output of brctl show command on server
the output of iptables -L -v and iptables -L -t nat -v
regards.
Michael.
kurt2439
--server.conf--
port 1194
proto udp
dev tap0
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh1024.pem
ifconfig-pool-persist ipp.txt
server-bridge 192.168.1.92 255.255.255.0 192.168.1.18 192.168.1.20
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3
--ifconfig on server--
br0 Link encap:Ethernet HWaddr 00:50:56:8F:00:01
inet addr:192.168.1.92 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::250:56ff:fe8f:1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:297430 errors:0 dropped:0 overruns:0 frame:0
TX packets:66332 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:23534143 (22.4 MiB) TX bytes:11163353 (10.6 MiB)
eth0 Link encap:Ethernet HWaddr 00:50:56:8F:00:01
inet6 addr: fe80::250:56ff:fe8f:1/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:5405128 errors:15 dropped:0 overruns:0 frame:0
TX packets:620710 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:766054181 (730.5 MiB) TX bytes:100593325 (95.9 MiB)
Interrupt:59 Base address:0x2024
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:241 errors:0 dropped:0 overruns:0 frame:0
TX packets:241 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:27180 (26.5 KiB) TX bytes:27180 (26.5 KiB)
tap0 Link encap:Ethernet HWaddr 66:AA:B9:2F:F7:0F
inet6 addr: fe80::64aa:b9ff:fe2f:f70f/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:742 errors:0 dropped:0 overruns:0 frame:0
TX packets:258966 errors:0 dropped:1699 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:71064 (69.3 KiB) TX bytes:21381950 (20.3 MiB)
--brctl show--
bridge name bridge id STP enabled interfaces
br0 8000.0050568f0001 no tap0
eth0
--iptables -L -v--
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
--iptables -L -t nat -v--
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
[root@pema-dev ~]# iptables -L -t nat -v
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
maikcat
can you please remove
ifconfig-pool-persist ipp.txt
from your server configs..
the funny thing is that everything looks ok... :roll:
what OS (distro) is your server?
what openvpn version are you using?
Michael.
dropje
Have you been able to tcpdump on a host in your LAN to check if icmp echo requests arrive?
Are you by any chance running this openvpn server on an ESX(i) platform?
kurt2439
--Versions--
Server: 2.2.0 (CentOS 5.6 - Virtual machine)
Client: 2.1.1 (Fedora 14 - Physical machine)
I removed ipp.conf txt line
Umm, it is a VM running on ESXi 5.0. You guess it. Uh oh for me?
I tried tcpdump -- silly not to have tried that before and the results are interesting. First some arp requests looking for the IP address and then the server replying with it's MAC. THEN ICMP echo requests that appear to be returned by the server but are never received by my client across the VPN. I'm not sure what this means as I'm not sure how the VPN connection forwards traffic. Interestingly, it keeps asking how to get to that IP though the echo requests are getting there
bodhi:~# tcpdump host 192.168.1.18
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
20:36:23.978423 arp who-has bodhi tell 192.168.1.18
20:36:24.034623 arp reply bodhi is-at 00:0c:29:1c:bb:36 (oui Unknown)
20:36:56.715175 IP 192.168.1.18 > bodhi: ICMP echo request, id 3810, seq 9, length 64
20:36:56.715909 arp who-has 192.168.1.18 tell bodhi
20:36:56.749649 arp reply 192.168.1.18 is-at 1e:06:72:d2:b8:1b (oui Unknown)
20:36:56.749680 IP bodhi > 192.168.1.18: ICMP echo reply, id 3810, seq 9, length 64
20:36:57.720828 IP 192.168.1.18 > bodhi: ICMP echo request, id 3810, seq 10, length 64
20:36:57.720876 IP bodhi > 192.168.1.18: ICMP echo reply, id 3810, seq 10, length 64
20:37:02.729136 arp who-has bodhi tell 192.168.1.18
20:37:02.729209 arp reply bodhi is-at 00:0c:29:1c:bb:36 (oui Unknown)
kurt2439
AHH, promiscuous mode on the virtual switch! I would throw up my hands except I've been bitten by that before a year or two ago when testing an OpenBSD firewall's routing in a virtualized environment. Bitten twice by the same dog. Ouch.
I do have another question though. Why is it that it takes so long to find the hosts after connecting? I'll try and connect to SAMBA and get nothing, then ping for 30 seconds and then it starts responding and SAMBA works. Then if I go on to another host, it still sometimes takes awhile for that to respond to ping. Is this just a delay due to arp having to be routed through so many channels?
dropje
To be honest it took me a while to figure it out also.. Ofcourse expected behaviour but still, icmp request gets received by the host and it sends a reply back but never arrives on the OpenVPN server? I was like, wtf! 🙂
I have a bridged setup and never experience any sluggish arp responds.. I'm not to sure on what to ask on this subject except for maybe connection issues? Moar tcpdump analyzing?
Are you sure a ping takes that long and it's not reverse lookups that aren't available? Try ping -n ?
kurt2439
well check this out. 1 minute and 15 seconds of arp requests (and replies!) before the ping starts working. This is after I had already been connected for several minutes and had been pinging another server on the subnet. I tried with ping -n and saw no difference.
tbodhi:~# tcpdump host 192.168.1.18
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
17:11:51.652468 arp who-has bodhi tell 192.168.1.18
17:11:51.687931 arp reply bodhi is-at 00:0c:29:1c:bb:36 (oui Unknown)
17:11:52.654963 arp who-has bodhi tell 192.168.1.18
17:11:52.654996 arp reply bodhi is-at 00:0c:29:1c:bb:36 (oui Unknown)
17:11:53.663677 arp who-has bodhi tell 192.168.1.18
17:12:56.670579 arp reply bodhi is-at 00:0c:29:1c:bb:36 (oui Unknown)
17:13:04.724597 arp who-has bodhi tell 192.168.1.18
17:13:04.724649 arp reply bodhi is-at 00:0c:29:1c:bb:36 (oui Unknown)
17:13:05.268098 IP 192.168.1.18 > bodhi: ICMP echo request, id 2476, seq 73, length 64
17:13:05.268169 IP bodhi > 192.168.1.18: ICMP echo reply, id 2476, seq 73, length 64
17:13:05.668278 IP 192.168.1.18 > bodhi: ICMP echo request, id 2476, seq 75, length 64
17:13:05.668317 IP bodhi > 192.168.1.18: ICMP echo reply, id 2476, seq 75, length 64
17:13:06.805036 IP 192.168.1.18 > bodhi: ICMP echo request, id 2476, seq 76, length 64
17:13:06.805195 IP bodhi > 192.168.1.18: ICMP echo reply, id 2476, seq 76, length 64
17:13:07.610336 IP 192.168.1.18.17500 > 192.168.1.255.17500: UDP, length 130
17:13:07.899556 IP 192.168.1.18 > bodhi: ICMP echo request, id 2476, seq 77, length 64
17:13:07.899597 IP bodhi > 192.168.1.18: ICMP echo reply, id 2476, seq 77, length 64
17:13:08.992104 IP 192.168.1.18 > bodhi: ICMP echo request, id 2476, seq 78, length 64
17:13:08.992143 IP bodhi > 192.168.1.18: ICMP echo reply, id 2476, seq 78, length 64
Sometimes it takes even longer -- I just waited 300 ping sequences (!!!!) for one of my hosts to start replying, but now it works fine. I do get this message on my openvpn server somewhat frequently, maybe it points to the issue?
Mar 2 17:34:28 host-dev kernel: eth0: received packet with own address as source address
