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

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

Thank you for your help. I'll be sure to blog about the solution when/if I figure it out. I'm sure more people will be using KVM and OpenVPN in combination in the future...

-- 
-a

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

On Dec 11, 2009, at 8:08 AM, Jan Just Keijser wrote:

> Schley Andrew Kutz wrote:
>>> 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.
>> 
>> 
>>  
> so the packet comes out of the tunnel but is not forwarded back into the bridge... hmmm sounds like a bridging/forwarding issue with Debian. I'm afraid I don't have a clue how to debug that, but I do know that this is becoming slightly off-topic ;-)
> You could try playing with some source routing options, e.g. set
> net.ipv4.conf.all.accept_source_route = 1
> (or the appropriate "cat 1 > /proc/....")
> 
> cheers,
> 
> JJK
>