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

    VPN connects, can't ping or connect to remote subnet

    OpenVPN
    2
    4
    637
    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.
    • K
      krypt36
      last edited by

      The tl;dr version is on the client side I get  manager: (tap0): new Tun device (/org/freedesktop/NetworkManager/Devices/5) and cannot get it to use TAP.

      I get no warnings or errors connecting.

      The client config is (as created from pfSense wizard):
      dev tap
      persist-key
      cipher AES-256-CBC
      auth SHA1
      tls-client
      client
      resolv-retry infinite
      remote xxx.xxx.xxx.xxx 1194 udp
      lport 0
      verify-x509-name "xyz.com" name
      auth-user-pass
      pkcs12 firewall-udp-1194-user.p12
      tls-auth firewall-udp-1194-user-tls.key 1
      ns-cert-type server
      comp-lzo

      My local subnet is 192.168.42.0/24
      Remote is 192.168.1.0/24

      I get assigned 192.168.1.200/24 and the routing tables update as expected (I think).

      ip r

      default via 192.168.42.1 dev eno1 proto static metric 100
      xxx.xxx.xxx.xxx via 192.168.42.1 dev eno1 proto static metric 100
      192.168.1.0/24 dev tap0 proto kernel scope link src 192.168.1.200 metric 50
      192.168.42.0/24 dev eno1 proto kernel scope link src 192.168.42.238 metric 100

      The ovpn wizard created firewall rules:
      IPV4 UDP * * WAN Address 1194 * none
      IPV4 * * * * * * none

      I can not connect in any way to any remote IP.

      ping 192.168.1.100

      PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
      From 192.168.1.200 icmp_seq=1 Destination Host Unreachable

      traceroute 192.168.1.100

      traceroute to 192.168.1.100 (192.168.1.100), 30 hops max, 60 byte packets
      1  magneto (192.168.1.200)  3045.336 ms !H  3045.300 ms !H  3045.297 ms !H

      magneto is my local machine, 192.168.1.100 exists on the remote network.

      Back to the tl;dr:
      I think the fact that "tap0" is actually a tun device is my issue.

      Any ideas are appreciated!

      1 Reply Last reply Reply Quote 0
      • luckman212L
        luckman212 LAYER 8
        last edited by

        Your openvpn client export package is up-to-date?

        On your ovpn server, tun is selected for "Device mode" near the top? Maybe something isn't saved right in your config, try re-saving it and then re-downloading your ovpn config from client export…

        1 Reply Last reply Reply Quote 0
        • K
          krypt36
          last edited by

          Redoing the config wizard resulted in the same config.

          The server config in pfsense is set to tap for mode. Interface is WAN, bridge interface is LAN.

          I found a guide that had me do the following:

          1. Interfaces –-> (assign)
          2. add an interface by pressing the "+" button
          3. in the drop down box next to the OPT1 interface that was created choose the open vpn server instance we just created
          4. goto Interfaces ---> OPT1
          5. Enable the interface and give it a Description
          6. goto Interfaces ---> (assign)
          7. choose the Bridges tab and then click the "+" button to add a bridge
          8. Hold the CTRL button and highlight both your LAN interface and the renamed OPT1 interface we just created.

          I then restarted OpenVPN...and got the same result. It connects, but is useless.

          1 Reply Last reply Reply Quote 0
          • luckman212L
            luckman212 LAYER 8
            last edited by

            so, you are actually wanting to use tap mode? Why do you need that if I may ask?  It is fairly uncommon and a bit trickier to make work, will not work for mobile devices and has several other caveats etc. Much better to stick with tun unless you really need broadcast traffic to traverse the tunnel for some reason…

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