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

    Remote site unable to connect resources behind pfSense at local site

    Scheduled Pinned Locked Moved General pfSense Questions
    5 Posts 3 Posters 348 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.
    • F
      fahad.ch
      last edited by

      Hello,

      I have just deployed a Netgate XG-7100 at my office. Let me call this as the local site. Everything internally works well. I have internet access and I am able to connect to resources in our remote site. However, users in remote site are unable to connect to resources at my office (local site). More information is below.

      • There is only one pfSense box and that is at my office (local site).
      • The connection between local and remote site is via MPLS circuit. I have made sure routing on that end is good.
      • pfSense gets its WAN connection from the MPLS router.
      • I know by default, pfSense doesn't reply to ping on WAN port. If I add a rule on WAN to allow ICMP from remote site's subnet, I can then ping pfSense from remote site. This confirms that traffic is reaching the firewall. However not to anything behind it.
      • I have tried adding allow all (any source, any destination, any port) rules on all WAN/LAN/VLAN10 networks, but that still doesn't solve the issue.
      • From within pfSense, I am unable to ping stuff on LAN from WAN port. (Diagnostics > Ping: Hostname: 10.65.15.6 – IP Protocol: ipv4 – Source Address: WAN – 100% packet loss) - Not sure if this by default.
      • pfSense box is fully updated and is running 2.4.4 R2.
      • Routing between vlans is also good on local site.

      Any help is appreciated.

      Thanks.

      1 Reply Last reply Reply Quote 0
      • M
        marvosa
        last edited by

        You mentioned there is only 1 PFsense box and it's on the local end, so what device is protecting the remote end?

        Can you provide a network map?

        1 Reply Last reply Reply Quote 0
        • F
          fahad.ch
          last edited by

          There is a cradelpoint on the other side.

          Local Site:
          MPLS router - 10.65.1.254
          pfSense WAN - 10.65.1.2
          vlan10 - 10.65.15.1
          LAN - 10.65.10.1

          Remote Site:
          MPLS Router - 10.55.1.254
          CradlePoint WAN - 10.55.1.2
          LAN - 192.168.1.1

          I hope this helps.

          1 Reply Last reply Reply Quote 0
          • M
            marvosa
            last edited by marvosa

            Can you post a network map, so we can see how things are connected and routed?

            Since your WAN IP is in a reserved range, you'd want to start with unchecking the "Block private networks and loopback addresses" option on your WAN. Has that been done?

            I am also not all that familiar with MPLS, is the circuit connecting the sites directly or are the two sites connected to a private cloud? Is the remote end's internet routed thru the local end?

            How do the routing tables look? Does the local site have a route to 192.168.1.1/24? Does the remote site have a route to 10.65.10.0/24 and 10.65.15.0/24?

            1 Reply Last reply Reply Quote 0
            • stephenw10S
              stephenw10 Netgate Administrator
              last edited by

              Unless you have disabled it pfSense will be NATing traffic for 192.168.1.1 to it's WAN IP, 10.65.1.2.

              Since we know the other side can ping that IP we know it has a route back, hence traffic from the pfSense LAN gets a response.

              But we don't know the remote side has a route to 10.65.10.X or 10.65.15.X. Nor do we know the MPLS infrastructure knows about those subnets. It looks like a missing route somewhere to me.

              Once you have that route in place you probably want to disable outbound NAT for 192.168.1.1 so devices at the remote site can see the correct source IP. That makes troubleshooting far easier for one thing.

              Steve

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