Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Openvpn : linux client, TAP0, L2 bridge

    Scheduled Pinned Locked Moved OpenVPN
    4 Posts 1 Posters 1.3k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S
      sebouley
      last edited by

      Hello everyone

      This is my first message here, and first of all thanks for a great product.

      I have a linux "openvpn client" that is connected on the internet on ETH1.

      I need this client to have another interface, thru a TAP tunnel, on a remote network.

      I wouldn't call this a "bridge" on the client side, as the client does not have (or need) an ETH1.
      I basically need an interface on the network behind the remote firewall.

      I created a TAP tunnel that seems to work, following this tutorial
      https://forum.pfsense.org/index.php?topic=46984.0

      The client is connected.

      From here I have to stop following "bridge" tutorials as I don't bridge eth1 and TAP0 (I don't have an ETH1)

      I tried adding an ip address directly on TAP0, which seems to work.
      However ARP REPLIES seems to get ignored.

      So my question is ;
      Wat is the proper way to achive wat Im' trying to achieve here ?

      I basically need the second network interface of the client to be a static IP on the remote network.

      The link also has to relay multicast, which is why I went directly to the TAP route.

      thanks !

      1 Reply Last reply Reply Quote 0
      • S
        sebouley
        last edited by

        ASCII art

        INTERNET

          \ –---------ETH0 [FIREWALL]  OPT1
            \                                                  +
            \ –------ETH0 [remote box] TAP0 /

        The remote box is a cloud VM. It need access to my OPT1, and it needs to be "part" of the OPT1 network.

        1 Reply Last reply Reply Quote 0
        • S
          sebouley
          last edited by

          When the remote box (behind the tunnel) tries to ping 172.17.1.1,

          I can see on 172.17.1.1 :

          20:44:39.178801 ARP, Request who-has 172.17.1.1 tell 172.17.199.199, length 46
          20:44:39.178819 ARP, Reply 172.17.1.1 is-at 00:50:56:88:72:09 (oui Unknown), length 28

          Which means that on the layer2 ; things seem to work

          However on the firewall itself

          20:44:35.981812 ARP, Request who-has 172.17.1.1 tell 172.17.199.199, length 28
          20:44:36.999968 ARP, Request who-has 172.17.1.1 tell 172.17.199.199, length 28
          20:44:37.997739 ARP, Request who-has 172.17.1.1 tell 172.17.199.199, length 28
          20:44:38.997725 ARP, Request who-has 172.17.1.1 tell 172.17.199.199, length 28

          The request goes thru (obviously, as we've seen it on the host) but the REPLY seems to get lost.. Probably the switch doesn't know it needs to send it to the firewall…

          This is beyond my understanding...

          any help appreciated

          1 Reply Last reply Reply Quote 0
          • S
            sebouley
            last edited by

            Hey everyone,

            just in case it helps someone in the future ; I found the solution, which was in a detail I forgot to tell about ; it's a vmware installation.

            My set-up was OK, the TAP VPN was up, and it was forwarding L2 trafic, however the vmware host simply discards any packat with a mac "not from the guest", which makes it impossible to have something like an ARP-proxy (or Layer2 vpn) on a vmware guest
            Solution is to allow "promiscuous" on the vswitch (altough I don't need promisc mode at all, I just need less paranoid enforcement of the MAC filtering)

            I tried disabling the other MAC-related option, but it did not work. Only works when allowing "promisc".

            Hopefully this helps someone someday

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.