Re: [Openvpn-users] Routed VPN cannot connect to bridge on same host

[Schley A. K. <sa...@gm...>]

> I'd run tcpdump on the box on various interfaces (eth0, eth2, br0, tun0) and then do a ping from the KVM client to the OpenVPN client. Who's responding and who isn't ? Also, what do the ARP tables show after a ping attempt?

Pinging the KVM guest from the VPN client while monitoring the tunnel.

[0]root@vault:~$ tcpdump -i tun0 'not tcp port 5901'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 96 bytes
08:25:51.286282 IP 192.168.1.10 > 192.168.0.50: ICMP echo request, id 65027, seq 0, length 64
08:25:52.284391 IP 192.168.1.10 > 192.168.0.50: ICMP echo request, id 65027, seq 1, length 64
08:25:53.286040 IP 192.168.1.10 > 192.168.0.50: ICMP echo request, id 65027, seq 2, length 64
08:25:54.283928 IP 192.168.1.10 > 192.168.0.50: ICMP echo request, id 65027, seq 3, length 64
08:25:55.283635 IP 192.168.1.10 > 192.168.0.50: ICMP echo request, id 65027, seq 4, length 64
08:25:56.286375 IP 192.168.1.10 > 192.168.0.50: ICMP echo request, id 65027, seq 5, length 64

Pinging the KVM guest from the VPN client while monitoring eth0.

[0]root@vault:~$ tcpdump -ni eth0 'ip and not tcp port 5901 and not tcp port 22 and not udp port 1194 and not tcp port 53'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
08:32:55.470810 IP 192.168.1.10 > 192.168.0.50: ICMP echo request, id 3076, seq 0, length 64
08:32:56.470674 IP 192.168.1.10 > 192.168.0.50: ICMP echo request, id 3076, seq 1, length 64
08:32:57.470514 IP 192.168.1.10 > 192.168.0.50: ICMP echo request, id 3076, seq 2, length 64
08:32:58.470537 IP 192.168.1.10 > 192.168.0.50: ICMP echo request, id 3076, seq 3, length 64

Pinging the KVM guest from the VPN client while monitoring br0.

[0]root@vault:~$ tcpdump -ni br0 'ip and not tcp port 5901 and not tcp port 22 and not udp port 1194 and not tcp port 53'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes
08:34:16.254188 IP 192.168.1.10 > 192.168.0.50: ICMP echo request, id 3588, seq 0, length 64
08:34:16.254692 IP 192.168.0.50 > 192.168.1.10: ICMP echo reply, id 3588, seq 0, length 64
08:34:17.253889 IP 192.168.1.10 > 192.168.0.50: ICMP echo request, id 3588, seq 1, length 64
08:34:17.254363 IP 192.168.0.50 > 192.168.1.10: ICMP echo reply, id 3588, seq 1, length 64
08:34:18.255824 IP 192.168.1.10 > 192.168.0.50: ICMP echo request, id 3588, seq 2, length 64
08:34:18.256442 IP 192.168.0.50 > 192.168.1.10: ICMP echo reply, id 3588, seq 2, length 64
08:34:19.253547 IP 192.168.1.10 > 192.168.0.50: ICMP echo request, id 3588, seq 3, length 64
08:34:19.254060 IP 192.168.0.50 > 192.168.1.10: ICMP echo reply, id 3588, seq 3, length 64

Here's the kicker. Without IP forwarding turned on, the last tcpdump doesn't produce any output. So the IP forwarding helped move me a step closer. The echo requests are getting sent to the bridge from the VPN clients and the replies are coming back. But the client still isn't getting a response.


-- 
-a

"The boys are thirsty in Atlanta and there's beer in Texarkana"  --Jerry Reed