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

    Possible Port maping issues.Traffic on mapped ports not going through.[RESOLVED]

    Scheduled Pinned Locked Moved NAT
    2 Posts 1 Posters 1.8k 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.
    • X
      x-ing
      last edited by

      Hello to everybody!

      I have pfsense (ver 1.2.2 upograded to 1.2.3-RC1 via webGUI)  installed on a PC with 2 network interface cards. The WAN interface is connected via rl0 and the LAN interface is xl0. The interface addresses are:
      WAN – set via DHCP
      LAN – 10.20.30.254 and DHCP is enabled from this interface, with the pfSense box acting as the DCHP server. I have several static leases assigned, and those work as well.
      Internet access works perfect.
      I have several port mappings assigned via NAT (created using the steps available in the documentation here). The map assigned for 443 (HTTPS) and 22 (SSH) are mapped to 10.20.30.254 and work. I also configured a map for RDP connections to one of my hosts that uses the static DHCP lease (10.20.30.10). And that’s were the problems begin.

      A firewall rule was created for it, but I cannot establish a connection. When I enable logging for this rule, I can see that the firewall passes the packet, as it is a match, but when I monitor the xl0 (LAN) interface either by using iftop or tcpdump, I cannot see any data being sent to 10.20.30.10 on port 3389 (RDP). I’ve even upgraded to 1.2.3-RC1 in hopes that it is a software glitch, but still no go :(

      Any assistance would be greatly appreciated!

      Thank you,

      Adrian

      Update: The LAN interface connects to one of the WBR-2310's switch interfaces that is used as a switch and wireless access points (DHCP disabled and host address for HTTP access is in the 192.168.0.0/24 network)

      1 Reply Last reply Reply Quote 0
      • X
        x-ing
        last edited by

        Issue was resolved by performing a clean re-install. Did not tyr to restore previous configuration file on new install.

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