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

    OpenVPN site to site - Can't reach client LAN

    Scheduled Pinned Locked Moved OpenVPN
    13 Posts 2 Posters 2.0k 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.
    • DerelictD Offline
      Derelict LAYER 8 Netgate
      last edited by

      I'll need a picture. I'm slow. See below for an example of the type of information required.

      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
      • J Offline
        jfennell
        last edited by

        Here's a rough diagram of how it looks right now.

        network.png
        network.png_thumb

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

          OK thanks. So what are you pinging (source/dest), where are you capturing, and what are you seeing in the capture?

          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
          • J Offline
            jfennell
            last edited by

            Scenario 1. (Successful)

            Ping
            Source: 10.0.0.5
            Destination: 172.20.5.182

            Packet Capture on LAN interface on Datacenter PFsense (Outbound NAT makes the source the LAN IP)

            20:32:12.480265 IP 172.20.5.180 > 172.20.5.182: ICMP echo request, id 50637, seq 2, length 64
            20:32:12.480549 IP 172.20.5.182 > 172.20.5.180: ICMP echo reply, id 50637, seq 2, length 64

            Scenario 2. (Fails)

            Ping
            Source: 172.20.5.182
            Destination: 10.0.0.5

            Packet Capture on LAN interface on Datacenter PFsense

            20:35:36.055371 IP 172.20.5.182 > 10.0.0.5: ICMP echo request, id 1, seq 489, length 40
            20:35:36.086793 IP 10.0.0.5 > 172.20.5.182: ICMP echo reply, id 1, seq 489, length 40

            Running wireshark on 172.20.5.182, the reply never comes.

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

              In the second capture are the MAC addresses associated with 172.20.5.182 different on the request and reply?

              Is there a gateway set on the LAN interface in the datacenter? Or is it DHCP?

              There is outbound NAT on the LAN interface there. The datacenter pfSense thinks LAN is a WAN (an interface with a gateway set or DHCP).

              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
              • J Offline
                jfennell
                last edited by

                The source and destination mac addresses are the same, just flipped on the reply.

                There's no gateway on the LAN interface. The server is a vm that is given a public and private interface. The LAN interface is set to the private interface's IP address.

                I added the nat outbound rule on the LAN interface for Scenario 1 to work. Without the rule, the source comes from the VPN endpoint 10.60.40.2 and it fails like scenario 2.

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

                  Something in your datacenter, man. If the frames are going out to the correct MAC address and and the packet is addressed to the correct IP address and you don't see the traffic arrive on that interface…

                  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
                  • J Offline
                    jfennell
                    last edited by

                    Yeah, I hope I was going to figure it out without looking more at the datacenter. The only thing I can notice that is different between the scenarios is in the first one, you can see the NAT working by translating the src of the Office LAN to the Datacenter PFsense LAN IP. But on scenario 2, you don't see the NAT working and the src IP is the office lan IP. If I remove the NAT for scenario 1, it looks just like scenario 2 and doesn't work so my thought was maybe it's a nat issue.

                    Thanks for you help.

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

                      Maybe they have something like AWS's source/dest check or some other ACLs in play. idk. But pcaps don't lie in general.

                      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
                      • J Offline
                        jfennell
                        last edited by

                        You were right. After dealing with the datacenter's support, we found I could enable IP spoofing on the LAN interface for the pfSense VM and after allowing that, it works fine without NAT.

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