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

[Jan J. K. <ja...@ni...>]

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