[plug] Too stupid to build VPN bridge ...

[Bernd Felsche]

"W.Kenworthy" <billk at iinet.net.au> writes:
>On Fri, 2006-06-16 at 10:59 +0800, Bernd Felsche wrote:
>> I've obviously grown too stupid to do this unaided:

>> Two networks; 192.168.3.0/24 and 192.168.2.0/24 need to be connected
>> so that clients in both can see each other without having to set
>> routes in every client. So I worked out that I needed a bridge.

>routing?  I find that openvpn often sets inappropriate routing on both
>the server and client - including default routes to the wrong place.
>Checked?

Routes appear to be set correctly, AFAICT.

>You might not be able to escape doing some scripted routing/un-routing
>commands ...

I've gone back to routed VPN seeing real improvement with bridged...
even after mangling stuff temporarily to have a common subnet of
192.168.3.0/24

iptables have been set to allow and forward on the tunnels.
Also:
echo 0 > /proc/sys/net/ipv4/ip_forward ; echo 1 > /proc/sys/net/ipv4/ip_forward

At the client LAN 192.168.2.0/24, the routes look like:
10.8.0.5       0.0.0.0         255.255.255.255 UH   0  0    0 tun0
203.59.14.16   0.0.0.0         255.255.255.255 UH   0  0    0 modem0
192.168.3.0    10.8.0.5        255.255.255.0   UG   0  0    0 tun0
192.168.2.0    0.0.0.0         255.255.255.0   U    0  0    0 eth0
10.8.0.0       10.8.0.5        255.255.255.0   UG   0  0    0 tun0
169.254.0.0    0.0.0.0         255.255.0.0     U    0  0    0 eth0
127.0.0.0      0.0.0.0         255.0.0.0       U    0  0    0 lo
0.0.0.0        203.59.14.16    0.0.0.0         UG   0  0    0 modem0

tun0      Link encap:UNSPEC  HWaddr 00-...
          inet addr:10.8.0.6  P-t-P:10.8.0.5  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

At the server; 192.168.3.0/24
10.8.0.2      0.0.0.0         255.255.255.255 UH   0  0    0 tun0
192.168.3.0   0.0.0.0         255.255.255.0   U    0  0    0 eth1
192.168.2.0   10.8.0.2        255.255.255.0   UG   0  0    0 tun0
10.8.0.0      10.8.0.2        255.255.255.0   UG   0  0    0 tun0
192.168.1.0   0.0.0.0         255.255.255.0   U    0  0    0 eth0
169.254.0.0   0.0.0.0         255.255.0.0     U    0  0    0 eth0
127.0.0.0     0.0.0.0         255.0.0.0       U    0  0    0 lo
0.0.0.0       192.168.3.1     0.0.0.0         UG   0  0    0 eth1

tun0      Link encap:Point-to-Point Protocol  
          inet addr:10.8.0.1  P-t-P:10.8.0.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:48 errors:0 dropped:0 overruns:0 frame:0
          TX packets:148 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:4032 (3.9 Kb)  TX bytes:12432 (12.1 Kb)

When I try to ping 192.168.2.1 (the client LAN server with the VPN
tunnel end) from 192.168.3.3; the server end of the VPN, tcpdump on
tun0 (@server) shows correct behaviour:

# ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
09:53:12.779997 IP 10.8.0.1 > 192.168.2.1: icmp 64: echo request seq 1
09:53:13.056178 IP 192.168.2.1 > 10.8.0.1: icmp 64: echo reply seq 1
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=276 ms

Same result the other direction:
# ping 192.168.3.3
PING 192.168.3.3 (192.168.3.3) 56(84) bytes of data.
64 bytes from 192.168.3.3: icmp_seq=1 ttl=64 time=286 ms

However; trying to ping a client LAN host other than the VPN
"gateway" (which is also the default gateway for the subnet) from
the server end of the VPN shows doesn't work.  tcpdump shows the
packets arriving at the client tunnel end but nothing is being sent
on the LAN (ethernet) interface:

# tcpdump -i tun0
tcpdump: WARNING: arptype 65534 not supported by libpcap - falling back to cooked socket
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
09:55:26.580835 IP 10.8.0.1 > 192.168.2.140: ICMP echo request, id 58695, seq 12, length 64
09:55:27.628780 IP 10.8.0.1 > 192.168.2.140: ICMP echo request, id 58695, seq 13, length 64

The server-side configuration has client-to-client set and is using
client-config-dir as per the OpenVPN howto; with due allowance for
different subnets.

I was going to try to force tunnel addresses as the real addresses
at both ends aren't at all visible; but my connection to the
customer site has dropped and I have to wait for their ADSL to come
back alive... grrrrrr.

Attemping to add the "correct" VPN gateway for the opposite LAN
produces "SIOCADDRT: Network is unreachable" even though I can ping
the nominal gateway.
-- 
/"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia
\ /  ASCII ribbon campaign | "Laws do not persuade just because
 X   against HTML mail     |  they threaten."
/ \  and postings          | Lucius Annaeus Seneca, c. 4BC - 65AD.