music wrote:
> Hallo.
> I've set up a openvpn server in debian linux machine and I have
> configured the client in my linux home pc connected to internet.
> I've set up the bridge.
> My ip server is 172.16.14.14 while at my home client is assigned
> 172.16.14.15.
> So the connection is up, I think.
> But I can't ping the two machines.
> What I miss?
>
> This is the server route:
> localnet * 255.255.255.0 U 0 0 0 br0
> default 172.16.14.1 0.0.0.0 UG 0 0 0 br0
>
> this is the client route:
> 192.168.100.1 * 255.255.255.255 UH 0 0 0 ppp0
> 172.16.14.0 172.16.14.14 255.255.255.0 UG 0 0 0 tap0
> 172.16.14.0 * 255.255.255.0 U 0 0 0 tap0
> default * 0.0.0.0 U 0 0 0 ppp0.

Please show the result of

ifconfig -a

in both computers.

Are the routing tables above complete (not stripped)?

--

Tauno Voipio
tauno voipio (at) iki fi

Tauno Voipio wrote:
> music wrote:
>> Hallo.
>> I've set up a openvpn server in debian linux machine and I have
>> configured the client in my linux home pc connected to internet.
>> I've set up the bridge.
>> My ip server is 172.16.14.14 while at my home client is assigned
>> 172.16.14.15.
>> So the connection is up, I think.
>> But I can't ping the two machines.
>> What I miss?
>>
>> This is the server route:
>> localnet * 255.255.255.0 U 0 0 0 br0
>> default 172.16.14.1 0.0.0.0 UG 0 0 0 br0
>>
>> this is the client route:
>> 192.168.100.1 * 255.255.255.255 UH 0 0 0 ppp0
>> 172.16.14.0 172.16.14.14 255.255.255.0 UG 0 0 0 tap0
>> 172.16.14.0 * 255.255.255.0 U 0 0 0 tap0
>> default * 0.0.0.0 U 0 0 0 ppp0.
>
> Please show the result of
>
> ifconfig -a
>
> in both computers.
>
> Are the routing tables above complete (not stripped)?
>

server ifconfig -a is:

br0 Link encap:Ethernet HWaddr 00:0F:FE:0D:24:64
inet addr:172.16.14.14 Bcast:172.16.14.255 Mask:255.255.255.0
inet6 addr: fe80::20f:feff:fe0d:2464/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:9407 errors:0 dropped:0 overruns:0 frame:0
TX packets:842 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:585461 (571.7 KiB) TX bytes:81354 (79.4 KiB)

eth0 Link encap:Ethernet HWaddr 00:0F:FE:0D:24:64
inet6 addr: fe80::20f:feff:fe0d:2464/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:25638 errors:0 dropped:0 overruns:0 frame:0
TX packets:839 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1898318 (1.8 MiB) TX bytes:87608 (85.5 KiB)
Interrupt:169

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:2 errors:0 dropped:0 overruns:0 frame:0
TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:210 (210.0 b) TX bytes:210 (210.0 b)

sit0 Link encap:IPv6-in-IPv4
NOARP MTU:1480 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:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

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)

tap1 Link encap:Ethernet HWaddr A6:E8:A1:84:98:77
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:77 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:10057 (9.8 KiB) TX bytes:0 (0.0 b)

home client ifconfig -a is:

eth0 Link encap:Ethernet HWaddr 00:02:3F:CF:84:2C
inet6 addr: fe80::202:3fff:fecf:842c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3156 errors:0 dropped:0 overruns:0 frame:0
TX packets:2293 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:326225 (318.5 KiB) TX bytes:235261 (229.7 KiB)
Interrupt:225 Base address:0x3000

eth1 Link encap:UNSPEC HWaddr
00-02-3F-3B-37-00-00-5B-00-00-00-00-00-00-00-00
BROADCAST 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:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:16 errors:0 dropped:0 overruns:0 frame:0
TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1280 (1.2 KiB) TX bytes:1280 (1.2 KiB)

ppp0 Link encap:Point-to-Point Protocol
inet addr:87.16.90.25 P-t-P:192.168.100.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:3107 errors:0 dropped:0 overruns:0 frame:0
TX packets:2238 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:254799 (248.8 KiB) TX bytes:182557 (178.2 KiB)

sit0 Link encap:IPv6-in-IPv4
NOARP MTU:1480 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:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

tap0 Link encap:Ethernet HWaddr 32:9D:3C:50:AB:96
inet addr:172.16.14.15 Bcast:172.16.14.255 Mask:255.255.255.0
inet6 addr: fe80::309d:3cff:fe50:ab96/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:17 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:2730 (2.6 KiB)

the correct and complete home client route is (linux command route):
Destination Gateway Genmask Flags Metric Ref Use
Iface
192.168.100.1 * 255.255.255.255 UH 0 0 0 ppp0
172.16.14.0 * 255.255.255.0 U 0 0 0 tap0
default * 0.0.0.0 U 0 0 0 ppp0

the server route is:
Destination Gateway Genmask Flags Metric Ref Use
Iface
localnet * 255.255.255.0 U 0 0 0 br0
default 172.16.14.1 0.0.0.0 UG 0 0 0 br0

music wrote:
> Tauno Voipio wrote:
>
>> music wrote:
>>
>>> Hallo.
>>> I've set up a openvpn server in debian linux machine and I have
>>> configured the client in my linux home pc connected to internet.
>>> I've set up the bridge.
>>> My ip server is 172.16.14.14 while at my home client is assigned
>>> 172.16.14.15.
>>> So the connection is up, I think.
>>> But I can't ping the two machines.
>>> What I miss?
>>>
>>> This is the server route:
>>> localnet * 255.255.255.0 U 0 0 0 br0
>>> default 172.16.14.1 0.0.0.0 UG 0 0 0 br0
>>>
>>> this is the client route:
>>> 192.168.100.1 * 255.255.255.255 UH 0 0 0 ppp0
>>> 172.16.14.0 172.16.14.14 255.255.255.0 UG 0 0 0 tap0
>>> 172.16.14.0 * 255.255.255.0 U 0 0 0 tap0
>>> default * 0.0.0.0 U 0 0 0 ppp0.
>>
>>
>> Please show the result of
>>
>> ifconfig -a
>>
>> in both computers.
>>
>> Are the routing tables above complete (not stripped)?
>>
>
> server ifconfig -a is:
>
> br0 Link encap:Ethernet HWaddr 00:0F:FE:0D:24:64
> inet addr:172.16.14.14 Bcast:172.16.14.255 Mask:255.255.255.0
> inet6 addr: fe80::20f:feff:fe0d:2464/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:9407 errors:0 dropped:0 overruns:0 frame:0
> TX packets:842 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:585461 (571.7 KiB) TX bytes:81354 (79.4 KiB)
>
> eth0 Link encap:Ethernet HWaddr 00:0F:FE:0D:24:64
> inet6 addr: fe80::20f:feff:fe0d:2464/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:25638 errors:0 dropped:0 overruns:0 frame:0
> TX packets:839 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:1898318 (1.8 MiB) TX bytes:87608 (85.5 KiB)
> Interrupt:169
>
> lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> inet6 addr: ::1/128 Scope:Host
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> RX packets:2 errors:0 dropped:0 overruns:0 frame:0
> TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:210 (210.0 b) TX bytes:210 (210.0 b)
>
> sit0 Link encap:IPv6-in-IPv4
> NOARP MTU:1480 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:0
> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
>
> 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)
>
> tap1 Link encap:Ethernet HWaddr A6:E8:A1:84:98:77
> BROADCAST MULTICAST MTU:1500 Metric:1
> RX packets:77 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:10057 (9.8 KiB) TX bytes:0 (0.0 b)
>
> home client ifconfig -a is:
>
> eth0 Link encap:Ethernet HWaddr 00:02:3F:CF:84:2C
> inet6 addr: fe80::202:3fff:fecf:842c/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:3156 errors:0 dropped:0 overruns:0 frame:0
> TX packets:2293 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:326225 (318.5 KiB) TX bytes:235261 (229.7 KiB)
> Interrupt:225 Base address:0x3000
>
> eth1 Link encap:UNSPEC HWaddr
> 00-02-3F-3B-37-00-00-5B-00-00-00-00-00-00-00-00
> BROADCAST 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:1000
> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
>
> lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> inet6 addr: ::1/128 Scope:Host
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> RX packets:16 errors:0 dropped:0 overruns:0 frame:0
> TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:1280 (1.2 KiB) TX bytes:1280 (1.2 KiB)
>
> ppp0 Link encap:Point-to-Point Protocol
> inet addr:87.16.90.25 P-t-P:192.168.100.1 Mask:255.255.255.255
> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
> RX packets:3107 errors:0 dropped:0 overruns:0 frame:0
> TX packets:2238 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:3
> RX bytes:254799 (248.8 KiB) TX bytes:182557 (178.2 KiB)
>
> sit0 Link encap:IPv6-in-IPv4
> NOARP MTU:1480 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:0
> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
>
> tap0 Link encap:Ethernet HWaddr 32:9D:3C:50:AB:96
> inet addr:172.16.14.15 Bcast:172.16.14.255 Mask:255.255.255.0
> inet6 addr: fe80::309d:3cff:fe50:ab96/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:17 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:100
> RX bytes:0 (0.0 b) TX bytes:2730 (2.6 KiB)
>
> the correct and complete home client route is (linux command route):
> Destination Gateway Genmask Flags Metric Ref Use
> Iface
> 192.168.100.1 * 255.255.255.255 UH 0 0 0 ppp0
> 172.16.14.0 * 255.255.255.0 U 0 0 0 tap0
> default * 0.0.0.0 U 0 0 0 ppp0
>
> the server route is:
> Destination Gateway Genmask Flags Metric Ref Use
> Iface
> localnet * 255.255.255.0 U 0 0 0 br0
> default 172.16.14.1 0.0.0.0 UG 0 0 0 br0

OK - or maybe wrong - depends on next answers.

How are the computers connected together?

I do not see the connection needed to bind the tunnel
ends together (usually using UDP port 1194).

--

Tauno Voipio
tauno voipio (at) iki fi

Tauno Voipio wrote:
> music wrote:
>> Tauno Voipio wrote:
>>
>>> music wrote:
>>>
>>>> Hallo.
>>>> I've set up a openvpn server in debian linux machine and I have
>>>> configured the client in my linux home pc connected to internet.
>>>> I've set up the bridge.
>>>> My ip server is 172.16.14.14 while at my home client is assigned
>>>> 172.16.14.15.
>>>> So the connection is up, I think.
>>>> But I can't ping the two machines.
>>>> What I miss?
>>>>
>>>> This is the server route:
>>>> localnet * 255.255.255.0 U 0 0 0 br0
>>>> default 172.16.14.1 0.0.0.0 UG 0 0 0 br0
>>>>
>>>> this is the client route:
>>>> 192.168.100.1 * 255.255.255.255 UH 0 0 0 ppp0
>>>> 172.16.14.0 172.16.14.14 255.255.255.0 UG 0 0 0 tap0
>>>> 172.16.14.0 * 255.255.255.0 U 0 0 0 tap0
>>>> default * 0.0.0.0 U 0 0 0 ppp0.
>>>
>>>
>>> Please show the result of
>>>
>>> ifconfig -a
>>>
>>> in both computers.
>>>
>>> Are the routing tables above complete (not stripped)?
>>>
>>
>> server ifconfig -a is:
>>
>> br0 Link encap:Ethernet HWaddr 00:0F:FE:0D:24:64
>> inet addr:172.16.14.14 Bcast:172.16.14.255 Mask:255.255.255.0
>> inet6 addr: fe80::20f:feff:fe0d:2464/64 Scope:Link
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:9407 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:842 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:0
>> RX bytes:585461 (571.7 KiB) TX bytes:81354 (79.4 KiB)
>>
>> eth0 Link encap:Ethernet HWaddr 00:0F:FE:0D:24:64
>> inet6 addr: fe80::20f:feff:fe0d:2464/64 Scope:Link
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:25638 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:839 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:1898318 (1.8 MiB) TX bytes:87608 (85.5 KiB)
>> Interrupt:169
>>
>> lo Link encap:Local Loopback
>> inet addr:127.0.0.1 Mask:255.0.0.0
>> inet6 addr: ::1/128 Scope:Host
>> UP LOOPBACK RUNNING MTU:16436 Metric:1
>> RX packets:2 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:0
>> RX bytes:210 (210.0 b) TX bytes:210 (210.0 b)
>>
>> sit0 Link encap:IPv6-in-IPv4
>> NOARP MTU:1480 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:0
>> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
>>
>> 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)
>>
>> tap1 Link encap:Ethernet HWaddr A6:E8:A1:84:98:77
>> BROADCAST MULTICAST MTU:1500 Metric:1
>> RX packets:77 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:10057 (9.8 KiB) TX bytes:0 (0.0 b)
>>
>> home client ifconfig -a is:
>>
>> eth0 Link encap:Ethernet HWaddr 00:02:3F:CF:84:2C
>> inet6 addr: fe80::202:3fff:fecf:842c/64 Scope:Link
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:3156 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:2293 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:326225 (318.5 KiB) TX bytes:235261 (229.7 KiB)
>> Interrupt:225 Base address:0x3000
>>
>> eth1 Link encap:UNSPEC HWaddr
>> 00-02-3F-3B-37-00-00-5B-00-00-00-00-00-00-00-00
>> BROADCAST 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:1000
>> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
>>
>> lo Link encap:Local Loopback
>> inet addr:127.0.0.1 Mask:255.0.0.0
>> inet6 addr: ::1/128 Scope:Host
>> UP LOOPBACK RUNNING MTU:16436 Metric:1
>> RX packets:16 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:0
>> RX bytes:1280 (1.2 KiB) TX bytes:1280 (1.2 KiB)
>>
>> ppp0 Link encap:Point-to-Point Protocol
>> inet addr:87.16.90.25 P-t-P:192.168.100.1
>> Mask:255.255.255.255
>> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
>> RX packets:3107 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:2238 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:3
>> RX bytes:254799 (248.8 KiB) TX bytes:182557 (178.2 KiB)
>>
>> sit0 Link encap:IPv6-in-IPv4
>> NOARP MTU:1480 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:0
>> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
>>
>> tap0 Link encap:Ethernet HWaddr 32:9D:3C:50:AB:96
>> inet addr:172.16.14.15 Bcast:172.16.14.255 Mask:255.255.255.0
>> inet6 addr: fe80::309d:3cff:fe50:ab96/64 Scope:Link
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:17 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:100
>> RX bytes:0 (0.0 b) TX bytes:2730 (2.6 KiB)
>>
>> the correct and complete home client route is (linux command route):
>> Destination Gateway Genmask Flags Metric Ref
>> Use Iface
>> 192.168.100.1 * 255.255.255.255 UH 0 0 0 ppp0
>> 172.16.14.0 * 255.255.255.0 U 0 0 0 tap0
>> default * 0.0.0.0 U 0 0 0 ppp0
>>
>> the server route is:
>> Destination Gateway Genmask Flags Metric Ref
>> Use Iface
>> localnet * 255.255.255.0 U 0 0 0 br0
>> default 172.16.14.1 0.0.0.0 UG 0 0 0 br0
>
> OK - or maybe wrong - depends on next answers.
>
> How are the computers connected together?
>
> I do not see the connection needed to bind the tunnel
> ends together (usually using UDP port 1194).
>

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.

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.

--

Tauno Voipio
tauno voipio (at) iki fi

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.

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?

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.

--

-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.
>

Scuse me but I don't understand very well.
My situation is:

server vpn is in a dmz with ip 172.16.14.14.
Dmz is controlled by a netscreen firewall.
The rules of this firewall are open in input udp 1194 while in output is
all open.
This firewall provides a nat between 172.16.14.14 and a public ip
xx.xx.xx.xx.
So from my client I connect to the public ip of the server.

music 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 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