<div dir="ltr">Hi,<br><br>I configured once again and now it works!<br>The problem was that I had not copied the keys from server to the client. If there is any other problem, I shall inform you.<br><br>Thanks,<br>Nazeem<br>
<br><br><div class="gmail_quote">2010/2/10 Ian Coetzee <span dir="ltr"><<a href="mailto:ubuntu@iancoetzee.za.net">ubuntu@iancoetzee.za.net</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Wed, Feb 10, 2010 at 8:48 AM, Nazeem äÌã áÏíä <<a href="mailto:nazeemnss@gmail.com">nazeemnss@gmail.com</a>> wrote:<br>
> hi,<br>
><br>
</div><div class="im">> I tried the openvpn idea. I was able to setp openvpn on both server and<br>
> client side. But I was neither able to ping to the other subnet nor send<br>
> ip-multicast.<br>
><br>
> I followed <a href="https://help.ubuntu.com/community/OpenVPN" target="_blank">https://help.ubuntu.com/community/OpenVPN</a> for the setup<br>
><br>
><br>
> The output of route -n on server:<br>
><br>
> ernel IP routing table<br>
> Destination     Gateway         Genmask         Flags Metric Ref    Use<br>
> Iface<br>
> 10.129.0.0      0.0.0.0         255.255.0.0     U     0      0        0 br0<br>
> 169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 br0<br>
> 0.0.0.0         10.129.1.250    0.0.0.0         UG    100    0        0 br0<br>
><br>
> So I think the route for the packets is the bridge.<br>
><br>
> Can you please tell me what I am missing. I did not use 2 NIC's on either<br>
> client or server. Do I have to use them?<br>
<br>
</div>Hi Nazeem<br>
<br>
Can you pastebin your server and client configs, with all the comments removed?<br>
<br>
Did you forward the relevant ports on your routers?<br>
<br>
Can you see that their is an established openvpn connection?<br>
<br>
Can you ping the OpenVPN server from the client and vise-versa?<br>
<br>
Regards<br>
<font color="#888888">Ian<br>
</font><div><div></div><div class="h5"><br>
><br>
><br>
> Nazeem<br>
><br>
><br>
> On Thu, Feb 4, 2010 at 6:57 AM, NoOp <<a href="mailto:glgxg@sbcglobal.net">glgxg@sbcglobal.net</a>> wrote:<br>
>><br>
>> On 02/03/2010 02:21 PM, Smoot Carl-Mitchell wrote:<br>
>> > On Wed, 2010-02-03 at 22:40 +0100, Werner Schram wrote:<br>
>> >><br>
>> >> On Wed, Feb 3, 2010 at 7:02 AM, Nazeem äÌã áÏíä <<a href="mailto:nazeemnss@gmail.com">nazeemnss@gmail.com</a>><br>
>> >> wrote:<br>
>> >> ><br>
>> >> > hi,<br>
>> >> > Can you suggest way of getting a multicast tunnel work. The<br>
>> >> > assumption is<br>
>> >> > that there is a unicast cloud in between two mbone networks. So we<br>
>> >> > need to<br>
>> >> > forward the multicast traffic over the unicast tunnel. Application is<br>
>> >> > for<br>
>> >> > video transmission.<br>
>> >> > -Nazeem<br>
>> >> ><br>
>> >><br>
>> >> I think you should be able to do it with openvpn. Using the tap setup,<br>
>> >> you can create a OSI layer 2 tunnel, which should be able to handle<br>
>> >> ip-multicast. You then need to update the routing tables in both<br>
>> >> networks to send multicast traffic to the tunnel in stead of the<br>
>> >> router.<br>
>> >> If you fully thrust the connection between the two networks, you could<br>
>> >> disable openvpn's encryption for better performance.<br>
>> ><br>
>> > You can also do this with SSH which I find simpler than openvpn to<br>
>> > configure (although I have done both).  Check out the -w argument to SSH<br>
>> > and the 'Tunnel' configuration parameter.  Tunnel lets you do either<br>
>> > layer 3 (point-to-point) or layer 2 (ethernet).  You do incur the<br>
>> > encryption overhead, but I would not run a VPN connection over the<br>
>> > Internet unencrypted.<br>
>> ><br>
>> ><br>
>><br>
>> Or, buy and use routers on each end that do the vpn encryption in<br>
>> hardware. I typically avoid software vpn solutions (except for roaming<br>
>> clients) for commercial/semi-commercial/private vpn networks. In the<br>
>> past I've used (and still do) Linksys/Cisco BEFVP41 routers on each end.<br>
>><br>
>> I'm sure that there are now more modern models that can do this as well,<br>
>> but the BEFVP41's (model 2/2.1) have been quite trustworthy. Setup is<br>
>> simple, the encryption takes place in the hardware so it's fast and<br>
>> doesn't require client software on each side of a direct connect, and<br>
>> both sides can be set up to autoconnect & use keepalive to stay up even<br>
>> with non-static ip addresses (I use <a href="http://dyndns.org" target="_blank">dyndns.org</a> for my non-commercial dsl<br>
>> connections).<br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>> ubuntu-users mailing list<br>
>> <a href="mailto:ubuntu-users@lists.ubuntu.com">ubuntu-users@lists.ubuntu.com</a><br>
>> Modify settings or unsubscribe at:<br>
>> <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-users" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-users</a><br>
><br>
><br>
><br>
> --<br>
> ubuntu-users mailing list<br>
> <a href="mailto:ubuntu-users@lists.ubuntu.com">ubuntu-users@lists.ubuntu.com</a><br>
> Modify settings or unsubscribe at:<br>
> <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-users" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-users</a><br>
><br>
><br>
<br>
</div></div>--<br>
<div><div></div><div class="h5">ubuntu-users mailing list<br>
<a href="mailto:ubuntu-users@lists.ubuntu.com">ubuntu-users@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-users" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-users</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>áÇ Çáå ÇáÇ Çááå ãÍãÏ ÑÓæá Çááå<br>
</div>