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

    [SOLVED] Really can not deal with rules and NAT

    Scheduled Pinned Locked Moved Firewalling
    3 Posts 1 Posters 2.2k 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.
    • J
      j2b
      last edited by

      Have read forum posts concerning pfSense containing logs on blocked packets, if there are doubles and lost FIN packets. But this time in my case it seams different - can not connect explicitly allowing connection, even using Quick rules from logs to allow connections.

      pfSense FW with NAT
      10.10.10.10 - WAN router external routed IP address
      192.168.10.1 - LAN router address internal

      10.10.10.11 - VIP for specific reasons located on WAN interface to connect to 192.168.10/24 LAN, as router have several OPT interfaces restricting internal VLANs.
      NAT setup is the following:
      Interface: WAN
      External address: 10.10.10.11 (VIP as stated above)
      Protocol: TCP
      External port range: 8888
      NAT IP address: 192.168.10.10 (from LAN interface - specific server)
      Local port: 8888

      By this setup I assume, that connections to VIP 10.10.10.11:8888 should be NATted to 192.168.10.10:8888. Hope, this is correct.

      I have a WAN Firewall rule, saying the following:
      Action: Pass
      Interface: WAN
      Protocol: TCP
      Source: Any (actually I have to specify exact host, but for now testing with any)
      Destination: 192.168.10.10/31 (single host or alias)
      Destination port range: 8888 to 8888
      State type: Keep state
      No logging.

      THE PROBLEM
      With this setup, I get connections for these hosts blocked by Default firewall rule, in logs showing, that TCP:S packet is blocked, which mean Syn. Can not connect from external host anyway.

      First strange things I noticed, that Firewall offers to enter LAN addresses in rules, which previously I thought different, that I have to allow connection to 10.10.10.11, instead of 192.168.10.10. But this works ok on other rules. Why is it so?

      Using FreeBSD 7.2-RELEASE-p5 i386

      Can anybody comment on these issues or direct me to wrong settings, if any? Additionally I have LAN interface rule (manually entered) - allow any to any, which probably should work for outgoing connections, as well as if these tests have to run on LAN interface, instead of WAN.

      1 Reply Last reply Reply Quote 0
      • J
        j2b
        last edited by

        Would like to add info for now:

        1. I run a packet capture, and find out, that, despite fw rule is for 192.168.10.10 IP on WAN interface, FW gets connection to VIP 10.10.10.11. I added additional FW rule to allow any connections to VIP on specific port. Run packet capture again - the same results. External system tries to send SYN packet to establish connection, but these first packets are blocked by default FW rule, despite expilcit allow rule

        2. I had an issue with asymetric routing, where packets were coming in via 10.10.10.11, but out - via FW WAN address. To be more precise, I registered Outgoing NAT rule, to move packets from this LAN interface out to any via VIP address: 10.10.10.11.

        The results still does not give me a clue and connection can not be established still.

        1 Reply Last reply Reply Quote 0
        • J
          j2b
          last edited by

          Was struggling with my issue for a couple of days, but really today, it turned out to be a problem of router restart. I could not imagine, that there could be a situation with FreeBSD to act like Microsoft products :) If something does not work, try to restart computer :).

          Anyway, restarted router, which was online for 1.5 years, and everything stepped in their places - rules started to work. To be honest, could not find any info relating to such issues, nor can comment it deeper. For now, issue is considered as solved.

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