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

    OpenVPN to management LAN

    Scheduled Pinned Locked Moved OpenVPN
    7 Posts 3 Posters 1.9k 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.
    • D
      dejl
      last edited by

      Hi,

      I have a problem to create a VPN tunel from my LANs to a Management LAN

      pfSense setup:
      WAN: 1.1.1.1

      LAN:
              VLAN1 - LAN1 - 172.16.30.0/24
              VLAN2 - LAN2 - 172.16.40.0/24
              VLAN3 - Management LAN - 192.168.254.0/24

      I have firewall rules set up so that LAN1 and LAN2 cannot access Management LAN.

      I'd like to create a VPN tunel to access the management lan.

      I've created a OpenVPN (with the wizard) and I'm able to connect to it but it's not possible to ping anything on the Management LAN.
      VPN network 192.168.253.0/24

      Here is the client setup:
      dev tun
      persist-tun
      persist-key
      cipher AES-128-CBC
      auth SHA1
      tls-client
      client
      resolv-retry infinite
      remote 1.1.1.1 1194 udp
      lport 0
      verify-x509-name "PrzegubServerCert" name
      auth-user-pass
      pkcs12 pfsense-udp-1194-dale.p12
      tls-auth pfsense-udp-1194-dale-tls.key 1
      ns-cert-type server

      The route is properly pushed to the client:
      Active Routes:
      Network Destination        Netmask          Gateway      Interface  Metric
                0.0.0.0          0.0.0.0      172.16.30.1    172.16.30.158    10
              127.0.0.0        255.0.0.0        On-link        127.0.0.1    306
              127.0.0.1  255.255.255.255        On-link        127.0.0.1    306
        127.255.255.255  255.255.255.255        On-link        127.0.0.1    306
            172.16.30.0    255.255.255.0        On-link    172.16.30.158    266
          172.16.30.158  255.255.255.255        On-link    172.16.30.158    266
          172.16.30.255  255.255.255.255        On-link    172.16.30.158    266
          192.168.253.1  255.255.255.255    192.168.253.5    192.168.253.6    30
          192.168.253.4  255.255.255.252        On-link    192.168.253.6    286
          192.168.253.6  255.255.255.255        On-link    192.168.253.6    286
          192.168.253.7  255.255.255.255        On-link    192.168.253.6    286
          192.168.254.0    255.255.255.0    192.168.253.5    192.168.253.6    30
              224.0.0.0        240.0.0.0        On-link        127.0.0.1    306
              224.0.0.0        240.0.0.0        On-link    192.168.253.6    286
              224.0.0.0        240.0.0.0        On-link    172.16.30.158    266
        255.255.255.255  255.255.255.255        On-link        127.0.0.1    306
        255.255.255.255  255.255.255.255        On-link    192.168.253.6    286
        255.255.255.255  255.255.255.255        On-link    172.16.30.158    266

      OpenVPN firewall rules are added by wizard.

      Any idea what else I need to add to get this working?

      1 Reply Last reply Reply Quote 0
      • DerelictD
        Derelict LAYER 8 Netgate
        last edited by

        OpenVPN firewall rules are added by wizard.

        Great.  What are they?  That's probably where the problem is.

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        1 Reply Last reply Reply Quote 0
        • D
          dejl
          last edited by

          WAN:
          IPv4 UDP * * WAN address 1194 (OpenVPN) * none OpenVPN wizard

          OpenVPN:
          IPv4 * * * * * * none OpenVPN wizard

          Nothing in NAT outbound.
          I thought this was the problem but couldn't find any information on needed outbound rules.
          I've tried to add some rules but it didn't work

          1 Reply Last reply Reply Quote 0
          • DerelictD
            Derelict LAYER 8 Netgate
            last edited by

            Pinging from OpenVPN to Management requires no more rules than that.

            Are you sure the devices on management allow pings from other subnets?

            Why are routes for LAN active at the same time? Are you trying to connect to OpenVPN from inside your network?  I have no idea if that'll work.  If so have you tried it from outside?

            LAN:
                    VLAN1 - LAN1 - 172.16.30.0/24

            172.16.30.0    255.255.255.0        On-link    172.16.30.158    266
            172.16.30.158  255.255.255.255        On-link    172.16.30.158    266

            Chattanooga, Tennessee, USA
            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
            Do Not Chat For Help! NO_WAN_EGRESS(TM)

            1 Reply Last reply Reply Quote 0
            • P
              phil.davis
              last edited by

              Yes, I think the OP has a client computer in LAN that has an OpenVPN client connecting to WAN port 1194, which then tries to access the Management network. In principle that should work. Maybe there is some problem with the way a "road warrior" OpenVPN can come out of LAN, NATed to public WAN IP and find itself connecting to port 1194 on the same WAN IP. This might be related to things that need NAT reflection.
              If you just want to connect from inside LAN, then your OpenVPN server could be listening on LAN address - and the client connects directly to that. Maybe that will work. And actually you can port forward from WAN address 1194 to LAN address 1194 so that an outside connection will find its way also.

              Trying just a ping to the inside tunnel IP ends would be interesting, and a traceroute from client to mgt lan to see if there is any evidence that the packet/s are rying to traverse the tunnel.

              As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
              If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

              1 Reply Last reply Reply Quote 0
              • D
                dejl
                last edited by

                @Derelict:

                Pinging from OpenVPN to Management requires no more rules than that.

                Are you sure the devices on management allow pings from other subnets?

                Why are routes for LAN active at the same time? Are you trying to connect to OpenVPN from inside your network?  I have no idea if that'll work.  If so have you tried it from outside?

                It's possible and that's how it should be set up.
                The management lan is a isolated lan for administration of the network and the only way to access it should be via VPN (from inside or outside that's why openVPN runs on WAN)
                The rules on all other LANs are blocking all traffic to the management lan.

                @phil.davis:

                Yes, I think the OP has a client computer in LAN that has an OpenVPN client connecting to WAN port 1194, which then tries to access the Management network. In principle that should work. Maybe there is some problem with the way a "road warrior" OpenVPN can come out of LAN, NATed to public WAN IP and find itself connecting to port 1194 on the same WAN IP. This might be related to things that need NAT reflection.
                If you just want to connect from inside LAN, then your OpenVPN server could be listening on LAN address - and the client connects directly to that. Maybe that will work. And actually you can port forward from WAN address 1194 to LAN address 1194 so that an outside connection will find its way also.

                Trying just a ping to the inside tunnel IP ends would be interesting, and a traceroute from client to mgt lan to see if there is any evidence that the packet/s are rying to traverse the tunnel.

                And thanks to your ideas I think I figured it out.

                The management network doesn't have a dhcp server (just like it should be since mostly it's to access switches that have static IPs).
                I think that the gateway on the switches isn't set correctly and when I ping something from a different subnet the switch doesn't know where to send the reply. (This is a gues but I think it might be it)

                I'll check it after Christmas but I think that a one to one NAT that will bind the VPN client IP address to an IP inside the management network might solve this.
                Or I'll just check all the equiptment and set the gateway properly.

                1 Reply Last reply Reply Quote 0
                • P
                  phil.davis
                  last edited by

                  You should be able to just add an Outbound NAT rule on LAN, source "the VPN tunnel network", destination LAN net, NAT to LAN address.

                  The traffic from your client device should have a source IP in VPN tunnel network, so will match that NAT rule, be translated to LAN address, go to the switch/es and the switches can answer.

                  As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                  If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

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