openvpn server bridge. - Networking

This is a discussion on openvpn server bridge. - Networking ; 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 ...

+ Reply to Thread
Results 1 to 20 of 20

Thread: openvpn server bridge.

  1. openvpn server bridge.

    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.

  2. Re: openvpn server bridge.

    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

  3. Re: openvpn server bridge.

    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

  4. Re: openvpn server bridge.

    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

  5. Re: openvpn server bridge.

    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.

  6. Re: openvpn server bridge.

    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

  7. Re: openvpn server bridge.

    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.

  8. Re: openvpn server bridge.

    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?

  9. Re: openvpn server bridge.

    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



  10. Re: openvpn server bridge.

    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.

  11. Re: openvpn server bridge.

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

  12. Re: openvpn server bridge.

    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

  13. Re: openvpn server bridge.

    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.

  14. Re: openvpn server bridge.

    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

  15. Re: openvpn server bridge.

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


    To see and share windows resources.

  16. Re: openvpn server bridge.

    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

  17. Re: openvpn server bridge.

    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.

  18. Re: openvpn server bridge.

    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

  19. Re: openvpn server bridge.

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

  20. Re: openvpn server bridge.

    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

+ Reply to Thread