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

    When are VIPs necessary for NAT, port fwrd?

    Scheduled Pinned Locked Moved HA/CARP/VIPs
    7 Posts 3 Posters 3.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.
    • N
      Norvell
      last edited by

      I originally posted this in the NAT section but got no response so I figured I'd try this one.

      1:1 NAT and port forwarding aren't working for me.  Everything is blocked by the default deny rule, even though I have rules allowing access.  From what I could find in the on-line docs, it sounds like I need Virtual IPs but I'm not sure.  The port forwarding instructions say to add VIPs depending on your WAN but I couldn't find how to determine if my WAN requires VIPs.

      Here's what I have:
          Two pfSense boxes in a CARP cluster, each box with three NICs (WAN, LAN, SYNC).
          14 public IPs
              1 for the cluster's gateway, a Cisco router connected to our fiber optic connection
              2 for the real WAN interfaces in the cluster
              1 for the WAN CARP virtual IP
              1 virtual IP for SNAT through VPN to a client's Cisco router (tunneling handled by Cisco
                      router on our end)
              9 IPs for 1:1 NAT to various servers on our LAN (mail, web, etc.)

      If I want to forward ports from the WAN CARP VIP to internal machines, do I need another VIP with the same address?  I tried creating one, but pfSense wouldn't let me since the WAN CARP VIP already exists.  Do I need VIPs for the real WAN IPs and rules/NAT assigments for them?  For 1:1 NAT for the other 9 IPs, do I need to create VIPs for each one in addition to the actual mappings under Firewall -> NAT -> 1:1?

      Maybe slightly off-topic, but are the 1:1 NAT mappings wide-open "holes" in the firewall or does pfSense block everything by default for NATed IPs?

      Thanks much.

      1 Reply Last reply Reply Quote 0
      • jimpJ
        jimp Rebel Alliance Developer Netgate
        last edited by

        A CAP VIP is already a VIP, you don't need another for port forwards on WAN. You can use 1:1 mappings on your other 9 IPs, so long as you have a CARP VIP created for each one.

        It's still default deny on 1:1 NAT IPs, so you will need appropriate firewall rules to allow traffic.

        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

        1 Reply Last reply Reply Quote 0
        • N
          Norvell
          last edited by

          Thanks for responding.

          @jimp:

          A CAP VIP is already a VIP, you don't need another for port forwards on WAN.

          So is there any other configuration necessary (beside the normal port forward instructions) for CARP WAN port forwards? because everything is being stopped by the default deny rule even though I have rules and port forward assignments that should let things through.  Other rules are working (for example, allowing DNS requests from the WAN is working because I see responses in TinyDNS's log).

          1 Reply Last reply Reply Quote 0
          • jimpJ
            jimp Rebel Alliance Developer Netgate
            last edited by

            As long as you pick the Interface as WAN, and the External address as the CARP IP, the port forward entry should work.

            And your firewall rules need to list the internal IP of the port forward as their destination, not the CARP IP.

            Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

            Need help fast? Netgate Global Support!

            Do not Chat/PM for help!

            1 Reply Last reply Reply Quote 0
            • N
              Norvell
              last edited by

              That's how I've configured the port forwards, but packets still stop at the default deny rule.

              Some possibly dumb questions:

              • This pfSense cluster is replacing an existing firewall/router.  Could stale ARP caches keep port forwards from working?

              • I had all the 1:1 NAT VIPs configured as Other instead of CARP and a firewall rule allowing WAN access to the internal IP of a 1:1 NAT is listed before any port forwarding rules.  Could that have fouled things up somehow and kept pfSense from seeing valid port forward rules?

              Since the company where I work is open 24/7, I have only a small window of time each day when I can switch to the pfSense cluster and try to figure out what I've done wrong.  So if there are any other things I can check or try, the more the better.  Thanks.

              1 Reply Last reply Reply Quote 0
              • C
                cweaver
                last edited by

                have you rebooted the router outside your firewall?  We just ran into similar and I found by rebooting the isp router/modem that the port forwards started working correctly.  (during testing I had to reboot it everytime I switched back and forth between pfsense and our old firewall)

                1 Reply Last reply Reply Quote 0
                • N
                  Norvell
                  last edited by

                  No, not yet, but I was planning on it:  I dug a little deeper in previous posts and found a similar problem which was fixed by rebooting a router.  After reading your reply, I'm confident that doing so (in conjunction with having the right type of VIPs) will take care of the problems I was having.  I can't try again for a few days because another project got elevated priority.  Thanks very much for your response.

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