[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

[Openvpn-users] Bridging VPN works except for the bridging


  • Subject: [Openvpn-users] Bridging VPN works except for the bridging
  • From: Michael Jinks <mjinks@xxxxxxxxxxxx>
  • Date: Tue, 2 Oct 2007 02:12:46 -0500

Hi, List.

I'm trying to build a bridging VPN between two Linux machines.  Each box
has two NICs, one (eth0) on the public network and one (eth1) on a private
switch.  I'd like machines on the private switches to be able to broadcast
to each other through the VPN so that I only have to maintain one DHCP
server for both segments, and it doesn't have to face the public net.

I've stepped through the bridging HOWTO, and I have things /mostly/
working.  The "client" machine connects to the "server", and they
successfully negotiate a connection up to the point that the client gets
an IP address assigned.

When I try to ping across the connection from either VPN peer, some 
traffic gets to the far end, but no replies come back.  Which traffic
gets through depends on the direction of the flow.  For example, while
running tcpdump in four different windows (watching br0 and tap0 on
each of the two machines), if I try to ping the "server" side
(10.1.1.2) from the "client" (10.1.1.50), I get:

  - On the client's tap0:
  00:35:53.336620 arp who-has 10.1.1.2 tell 10.1.1.50
  00:35:53.338668 arp reply 10.1.1.2 is-at 00:0c:29:6f:f9:8e

  - On the client's br0:
  00:35:53.338668 arp reply 10.1.1.2 is-at 00:0c:29:6f:f9:8e

  - On the server's br0:
  00:35:53.329712 arp who-has 10.1.1.2 tell 10.1.1.50
  00:35:53.329765 arp reply 10.1.1.2 is-at 00:0c:29:6f:f9:8e

  - On the server's tap0:
  00:35:53.329712 arp who-has 10.1.1.2 tell 10.1.1.50
  00:35:53.329770 arp reply 10.1.1.2 is-at 00:0c:29:6f:f9:8e

(Note, no "who-has" ever appears on the client's br0, only the replies,
which struck me as odd.)

If I try to ping the client side from the server, still running tcpdump
on the same four interfaces, I get this on all of them:

  00:45:56.203355 arp who-has 10.1.1.50 tell 10.1.1.2

No arp replies appear anywhere.

However, if I've recently tried to pass traffic from the client to the
server, that changes.  Then, there will be a few seconds where tcpdump
shows the ICMP echo request going through, it makes it all the way to
tap0 on the client, but no replies are generated.  After three or four
seconds with no client->server traffic, we go back to arp who-has
requests.

While trying to ping the client (.50) from the server (.2), the server's
arp table shows:

Address             HWtype  HWaddress      Flags Mask           Iface
10.1.1.50                  (incomplete)                         br0

If the client tries to ping the server at the same time, it changes:

10.1.1.50           ether   16:31:B2:33:B7:D0   C               br0

...and the echo requests start to appear on client:tap0, but it
generates no replies.

While the server tries to ping the client, the client's arp table shows
nothing for the server.  If client tries to ping the server, the client
side arp table shows:

10.1.1.2                   (incomplete)                         tap0

One thing I notice is that the "sever" shows br0 as the gateway 
interface (whether the record is complete or not), while the client
always shows tap0.  I don't know if that matters.

I've been over my firewalling.  Both machines initialize their rules
from a copy of the same shell script, and both include the iptables
commands from the bridging HOWTO (ACCEPT for anything inbound on tap0
or br0, and for anything forwarding on br0) before any DROP or REJECT
rules.

Running "ebtables -t broute -L" just shows a default policy of "ACCEPT"
on both hosts, which is what I want, right?

Also on both hosts:

  $ cat /proc/sys/net/bridge/bridge-nf-*
  0
  0
  0
  0

  $ cat /proc/sys/net/ipv4/ip_forward 
  1

That pretty much sums up where I am so far; I don't know why it isn't
working and I'm not sure where to look for more information.  The
remainder of this mail is just copies of config files from both
machines.

The server's openvpn.conf file looks like:

  local 128.135.119.178
  port 1194
  proto udp
  dev tap0
  ca /etc/openvpn/keys/ca.crt
  cert /etc/openvpn/keys/server.crt
  dh /etc/openvpn/keys/dh1024.pem
  ifconfig-pool-persist ipp.txt
  server-bridge 10.1.1.2 255.255.255.0 10.1.1.50 10.1.1.100
  client-to-client
  keepalive 10 120
  comp-lzo
  user nobody
  group nobody
  persist-key
  persist-tun
  status openvpn-status.log
  verb 5

...And here's the client's:

  client
  dev tap0
  proto udp
  remote bossy.uchicago.edu 1194
  resolv-retry infinite
  nobind
  user nobody
  group nobody
  persist-key
  persist-tun
  ca /etc/openvpn/keys/ca.crt
  cert /etc/openvpn/keys/client.crt
  key /etc/openvpn/keys/client.key
  ns-cert-type server
  comp-lzo
  verb 5

These are both Gentoo machines, their network config files are pretty
self-explanatory.  Server's entire network config file:

  depend_br0() {
          need net.tap0 net.eth1
  }
  tuntap_tap0="tap"
  config_eth1=( "null" )
  config_tap0=( "0.0.0.0 promisc" )
  bridge_br0=( "eth1 tap0" )
  config_br0=( "10.1.1.2 netmask 255.255.255.0 broadcast 10.1.1.255" )

  config_eth0=( "128.135.119.178 netmask 255.255.255.0 broadcast
  128.135.119.255" )

  routes_eth0=( "default via 128.135.119.1" )

And here's the client's network config:

  depend_br0() {
          need net.tap0 net.eth1
  }
  config_eth0=( "128.135.23.130 netmask 255.255.255.0 broadcast 128.135.23.255" )
  routes_eth0=( "default via 128.135.23.1" )
  config_eth1=( "null" )
  tuntap_tap0="tap"
  config_tap0=( "0.0.0.0 promisc" )
  bridge_br0=( "eth1 tap0" )
  config_br0=( "null" )
______________________
OpenVPN mailing lists
https://lists.sourceforge.net/lists/listinfo/openvpn-users