openvpn server bridge.

music <music@musi.ca> wrote:

> server ifconfig -a is:
....

> tap0 Link encap:Ethernet HWaddr 16:6A:E7:CE:72:EC
> inet6 addr: fe80::146a:e7ff:fece:72ec/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:8670 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

All TX packets are dropped. If you can find out why and fix it then
it may well solve your problem.

Sorry, but I am VPN and bridge impaired and so have no idea what is
causing the packet drops.

HTH
--
/* 97.3% of all statistics are made up. */

Clifford Kite wrote:
> music <music@musi.ca> wrote:
>
>
>>server ifconfig -a is:
>
> ...
>
>
>>tap0 Link encap:Ethernet HWaddr 16:6A:E7:CE:72:EC
>> inet6 addr: fe80::146a:e7ff:fece:72ec/64 Scope:Link
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:0 errors:0 dropped:8670 overruns:0 carrier:0
>> collisions:0 txqueuelen:0
>> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
>
>
> All TX packets are dropped. If you can find out why and fix it then
> it may well solve your problem.
>
> Sorry, but I am VPN and bridge impaired and so have no idea what is
> causing the packet drops.
>
> HTH


This is the Ethertap interface. It is an Ethernet-like
interface at the network end and a character device at
the tunnel daemon end. It will drop the packets if the
daemon at the character device end is not picking them up.
For OpenVPN this is probably because the tunnel outside
connection is not working.

I've been trying to figure out the network topology thought
out by the OP to see why the connection is not achieved,
but I've not yet seen any way to make the UDP packets to
travel the distance.

As far as I've seen in the discussion, there is no connection
from the client to the Net for sending the encapsulated
and encrypted packets to the server, and I'm not sure whether
they'll make it through the NAT at the server end.

--

Tauno Voipio
tauno voipio (at) iki fi

Tauno Voipio wrote:
> music wrote:
>> music wrote:
>>
>>> Tauno Voipio wrote:
>>>
>>>> music wrote:
>>>>
>>>>>
>>>>> Server vpn is in dmz controlled by a netscreen 204 firewall.
>>>>> Client has an adsl internet connection.
>>>>> Netscreen firewall opens upd 1194 in input while output is all open.
>>>>> Client has no firewall rules.
>>>>> I see that, when I try to ping server to client or client to
>>>>> server, there are many arp requests without answer.
>>>>> Sorry for my bad english.
>>>>> If you need more information ask me, thank you.
>>>>
>>>>
>>>>
>>>> A VPN is a connection of two private networks using
>>>> a public IP connection to transport the packets. To
>>>> do this, we need two IP addresses at each end of the
>>>> connection (called a tunnel): one to use the public
>>>> Internet (tunnel outside address) and another for the
>>>> private network data (tunnel inside address).
>>>>
>>>> OpenVPN provides two different ways of transferring
>>>> internal network data: routing IP packets (using tun0)
>>>> or bridging link-level (Ethernet) frames (using tap0).
>>>>
>>>> In your case, the inside ends of the tunnel seem to
>>>> be set up for transporting link-level (Ethernet)
>>>> frames to bridge the internal network segments
>>>> together. I do not see the necessary outside
>>>> interfaces and their addresses (for UDP port 1194)
>>>> in the setup you posted.
>>>>
>>>
>>> Do you mean the public ip?
>>> For client side I have an adsl internet connection with dinamic
>>> public ip.
>>> For server side the public ip is 82.85.10.18 and the netscreen
>>> firewall makes a nat between 172.16.14.14 and the public ip to allow
>>> connections from/to internet.
>>
>>
>> My vpn server has only one nic, the public ip is a NAT of the private ip.
>> May be a problem?
>
> Yes - for connecting the tunnel ends together, you need
> to port forward the UDP port of the public IP to the server,
> and configure your client VPN to connect to the server's
> public IP.
>
> It is not a good idea to bridge the VPN segments in a setup
> like this - the routing at the server may be impossible to
> set up properly. Probably you should have another private
> subnet for the tunnel inside addresses.
>

I want to say that if I configure openvpn using routing then it works.
If I use bridge it doesn't work.

music wrote:
>
> I want to say that if I configure openvpn using routing then it works.
> If I use bridge it doesn't work.

That's right - the bridge cannot distinguish if a packet
is an encapsulated packet to be sent as is or a packet
to be bridged for encapsulation - you will create a
bridge loop with bridging and a single interface.

Would you mind to tell why you do want to use a bridged
connection? For Windows NETBEUI packets?

--

Tauno Voipio
tauno voipio (at) iki fi

> Would you mind to tell why you do want to use a bridged
> connection? For Windows NETBEUI packets?

To see and share windows resources.

music wrote:
>> Would you mind to tell why you do want to use a bridged
>> connection? For Windows NETBEUI packets?
>
>
> To see and share windows resources.

You should be able to use them even in a routed configuration.

The Windows boxes must be set up to use NETBEUI on top of
TCP/IP for it. To see the resource names, a Wins server needs
to be set up and configured in the clients.

--

Tauno Voipio
tauno voipio (at) iki fi

Tauno Voipio wrote:
> music wrote:
>>> Would you mind to tell why you do want to use a bridged
>>> connection? For Windows NETBEUI packets?
>>
>>
>> To see and share windows resources.
>
> You should be able to use them even in a routed configuration.
>
> The Windows boxes must be set up to use NETBEUI on top of
> TCP/IP for it. To see the resource names, a Wins server needs
> to be set up and configured in the clients.
>

But we don't have a wins server.

music wrote:
> Tauno Voipio wrote:
>
>> music wrote:
>>
>>>> Would you mind to tell why you do want to use a bridged
>>>> connection? For Windows NETBEUI packets?
>>>
>>>
>>>
>>> To see and share windows resources.
>>
>>
>> You should be able to use them even in a routed configuration.
>>
>> The Windows boxes must be set up to use NETBEUI on top of
>> TCP/IP for it. To see the resource names, a Wins server needs
>> to be set up and configured in the clients.
>>
>
> But we don't have a wins server.

It is not too difficult to set up in any Windows machine.
The details are off-topic for a Linux group.

--

Tauno Voipio
tauno voipio (at) iki fi

>> But we don't have a wins server.
>
> It is not too difficult to set up in any Windows machine.
> The details are off-topic for a Linux group.
>

You say that routing is best than bringing in openvpn?

music wrote:
>>> But we don't have a wins server.
>>
>>
>> It is not too difficult to set up in any Windows machine.
>> The details are off-topic for a Linux group.
>>
>
> You say that routing is best than bringing in openvpn?

You can bridge, but the interface carrying the encoded
packets must not be a part of the bridge - you do need
at least two interfaces.

--

Tauno Voipio
tauno voipio (at) iki fi