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

    OpenVPN client TAP bridge - reconnect problem

    Scheduled Pinned Locked Moved
    OpenVPN
    netgate-2100 openvpn bridge
    3
    8
    1.3k
    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.
    • R
      rvtk
      last edited by

      Hello,
      I have problem with bridged OpenVPN client TAP interface.

      Setup:

      • Netgate 2100
      • pfSensePlus 23.01 (plus-RELENG_23_01-n256037-6e914874a5e)
      • OpenVPN 2.6_beta1

      Interfaces:

      • mvneta1.30 - VLAN for local servers
      • ovpnc2 - OpenVPN client TAP interface for servers in datacenter
      • bridge0 (2 members: mvneta1.30 and ovpnc2)

      It seems working fine until tunnel goes down - then it cannot be reconnected. Log messages:

      Mar 30 10:30:36	openvpn	70329	TUN/TAP device /dev/tap2 opened
Mar 30 10:30:36	openvpn	70329	/sbin/ifconfig ovpnc2 172.29.100.4/24 mtu 1500 up
Mar 30 10:30:36	openvpn	70329	FreeBSD ifconfig failed: external program exited with error status: 1
Mar 30 10:30:36	openvpn	70329	Exiting due to fatal error

      Restarting OpenVPN client service produces same error.
      I tried manually execute ifconfig command from log above:

      [23.01-RELEASE][root@fw-pf]/root: /sbin/ifconfig ovpnc2 172.29.100.4/24 mtu 1500 up
ifconfig: ioctl SIOCSIFMTU (set mtu): Operation not supported

      Workaround to establish tunnel:

      1. Remove ovpnc2 member from bridge
      2. Restart OpenVPN client service
      3. Add ovpnc2 to bridge

      Is there something wrong in my settings, or is it bug?

      G B 2 Replies Last reply Reply Quote 2
      • G
        GrilleGustav @rvtk
        last edited by

        @rvtk We also have the same problem with pfSense plus 23.05.1
        If we configure an IP address range on the OpenVPN tunnel, our client can not connect to the VPN server, if the client interface is already bridged to another interface.
        Remove the ip address range from the OpenVPN server and then your clients are able to connect.
        Seem to be a problem with OpenVPN 2.6.4
        The same configuration was working fine with pfSense 22.01/2.6.0 and OpenVPN 2.5.4

        B 1 Reply Last reply Reply Quote 0
        • B
          brepo @GrilleGustav
          last edited by

          @GrilleGustav we have the same problem

          https://redmine.pfsense.org/issues/15151

          the only problem is Jim Pinge :)

          in general if you make a bridge after putting together a tunnel, it works as you would like ...

          only write a script, not sure why pfsens has a problem with such a simple configuration that works on any Linux ....

          1 Reply Last reply Reply Quote 0
          • B
            brepo @rvtk
            last edited by

            @rvtk

            Is there anyone here on this forum who has vision and can realistically describe this problem of lack of functionality ?

            Because Jim, it will only write that you have to do as in the manual and that it can not be done, and that's all in all.

            I understand that the problem may affect a small group of people, because probably few people use TAP in such a way, but at least does anyone have a see if the problem is on the side of pfsense / openvpn or the integration itself between the two software ?

            R 1 Reply Last reply Reply Quote 0
            • R
              rvtk @brepo
              last edited by

              @brepo Is it possible to change your configuration according to Jim's advice / manual instructions?

              ... Normally with a tap bridge you don't have an interface address / tunnel network on the member interfaces, only on the bridge interface itself. ...

              Have you tried set the IP address only on the bridge interface?
              If I am correct, the cause of the "problem" is an attempt to set the MTU on a bridge member interface, which is not allowed.

              B 1 Reply Last reply Reply Quote 0
              • B
                brepo @rvtk
                last edited by brepo

                @rvtk

                Yes, I checked every option.

                Until pfsense allows again to do lan bridge with openvpn it will not work.

                Today we are testing an analogous configuration on opensense and there it works normally.

                OPNsense 23.7.11-amd64
                FreeBSD 13.2-RELEASE-p7
                OpenSSL 1.1.1w

                In this version you make a normal bridge and have no such message:
                FreeBSD ifconfig failed: external program exited with error status: 1

                here's how I got it done:
                [server]
                172.20.2.0/24 link#30 U 21 1500 ovpns3
                192.168.200.0/24 172.20.2.200 UGS 17 1500 ovpns3

                [client]
                ipv4 172.20.2.0/24 link#10 U NaN 1500 ovpnc1
                ipv4 172.20.2.200 link#10 UHS NaN 16384 lo0 Loopback
                ipv4 192.168.10.0/24 172.20.2.1 UGS NaN 1500 ovpnc1
                ipv4 192.168.20.0/24 172.20.2.1 UGS NaN 1500 ovpnc1
                ipv4 192.168.30.0/24 172.20.2.1 UGS NaN 1500 ovpnc1

                = such a combination of L2+L3 gives unlimited possibilities, this creates a virtual cable and acts as a physical connection (layer 1)

                Everything can be managed by Client Specific Overrides and adding routing from the server side.

                arping -v -c 3 -i ovpns3 192.168.200.1 output:

                This box: Interface: ovpns3 IP: 172.20.2.1 MAC address: 58:9c:fc:10:ff:df
                ARPING 192.168.200.1
                42 bytes from 58:9c:fc:10:ff:d8 (192.168.200.1): index=0 time=53.449 msec
                42 bytes from 58:9c:fc:10:ff:d8 (192.168.200.1): index=1 time=72.467 msec
                42 bytes from 58:9c:fc:10:ff:d8 (192.168.200.1): index=2 time=45.220 msec

                --- 192.168.200.1 statistics ---
                3 packets transmitted, 3 packets received, 0% unanswered (0 extra)
                rtt min/avg/max/std-dev = 45.220/57.045/72.467/11.411 ms

                B 1 Reply Last reply Reply Quote 0
                • B
                  brepo @brepo
                  last edited by

                  @brepo

                  For those who would have once sought this solution:

                  1. OPNsense - works fine in this area (OPNsense 23.7.11-amd64),
                  2. pfsense - still maintains that it can't work - the approach of this netgate company is unprofessional, I suppose these people working on the communication front have no idea about advanced configurations and therefore maintain that it is not a bug
                  3. as you take care of the router at home, do not advise others who need professional help
                  4. i also asked OPNsense company, for feedback on pfsense company's answers, and asking if they too plan to exclude such configurations someday - i am waiting for a response
                  B 1 Reply Last reply Reply Quote 0
                  • B
                    brepo @brepo
                    last edited by

                    @brepo

                    • I feel a little sorry for myself, because I spent more than 10 years with pfsense and everything suited me before :)
                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post