Re: xen and openvpn

[brook%biology.nmsu.edu@localhost (Brook Milligan)]

I discovered the source of the problem.  With all my worrying about
the openvpn setup I neglected to notice that the default route was set
incorrectly.  Now it works fine.  Sorry for the noise.

Just for the record, I'll also respond to comments below.

Greg Troxel writes:
 >   Obviously you should have the dom0 set up to bridge from the dom0
 >   physical interface to xennetN.  right?

Yes, and the bridge worked fine for other domUs.

 >   Check that you aren't doing any bridge ipfiltering you don't mean to.

No filtering or NAT.

 >   You have a working box which is running on one interface.  So why are
 >   y0u using xennet0 and xennet1?  What IP addresses are on both?  This
 >   makes no sense to me, and isn't part of straightforwardly moing the
 >   openvpn router to a domU from physical hardware.

I am using two interfaces to mimic a normal router connected to two
different network segments.  I also have other domUs that have two
interfaces and are routing between networks but without openvpn.  This
works fine.

Is it better to use just one interface with aliased IP addresses?

 >   You say inbound packets get to servers, and the question is the return
 >   packets.  You can see them with tcpdump on tun0 on the domU
 >   (presumably).  But what about on xennet1 on the domU, on xvifN.M on
 >   the dom0, and the e.g. bge0 on the dom0?

I can see them on the tun0 and the xvifN.M interface of the dom0.

 >   When you run tcpdump on the client, do you not see the tunneled packets?

I didn't.

 > My best guess, with inadequate information, is that there is something
 > funky about NAT due to having two interfaces instead of one on the
 > openvpn router.

Actually, that was not the problem at all.  Simply the default route
problem.  I'm not certain why I did not see evidence of that in the
tcpdump output, though.  Oh well.  Once again, sorry.

Cheers,
Brook