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

    IPv6 NAT / Port forwarding not working.

    Scheduled Pinned Locked Moved 2.1 Snapshot Feedback and Problems - RETIRED
    3 Posts 2 Posters 9.6k 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.
    • M
      mrzaz
      last edited by

      I'm trying to get NAT (Port forwarding) working on pfSense with IPv6 and have some problems.
      Running on latest build 2012-06-13

      I have a GIF-tunnel working towards Tunnelbroker.net and have no problem reaching IPv6 internet
      and I could also see in Firewall logs that internet is reaching the router.

      My public IP is: 2001:470:27:dd5::2
      My "Routed prefix" is: 2001:470:28:dd5::/64

      I also have a local client setup with stateless_config "Unmanaged" RA.mode
      Ethernet adapter Local Area Connection:

      Connection-specific DNS Suffix  . :
        IPv6 Address. . . . . . . . . . . : 2001:470:28:dd5:39cf:c6b0:4657:c4ed
        Temporary IPv6 Address. . . . . . : 2001:470:28:dd5:9d10:2041:bd1b:6e7c
        Link-local IPv6 Address . . . . . : fe80::39cf:c6b0:4657:c4ed%10
        Default Gateway . . . . . . . . . : fe80::82ee:73ff:fe18:9ab7%10

      On this machine, I have a IPv6 aware FTP-server setup tied to both IPs.
      Also the firewall is temporary disabled for all interfaces in this machine.

      I have setup a NAT entry on the TUNNELBROKER-GIF interface with:

      Interface: TUNNELBROKER
      Protocol: TCP
      Source: *
      Source port range: *
      Destination: TUNNELBROKER address
      Destination port range: 21 (FTP)
      Redirect target IP: 2001:470:28:dd5:39cf:c6b0:4657:c4ed
      Redirect target port: 21 (FTP)

      I have added a "Log packets that are handled" entry so I should see this in the Firewall log.

      When I do a port-scan on port 21 from internet I could see the following in the firewall log:
      BLOCK Jun 14 11:18:14 TUNNELBROKER [2a02:348:82:cb69::1]:46957 [2001:470:27:dd5::2]:21 TCP:S

      EVEN if the firewall-rule is defined (autocreated):
      IPv6 TCP * * 2001:470:28:dd5:39cf:c6b0:4657:c4ed 21 (FTP) * none   NAT FTP_IPv6

      BUT, the packet is NOT forwarded to the client-machine.  (as seen with wireshark)

      I then disabled this rule and made a globally open:
      IPv6 TCP * * * 21 (FTP) * none

      Now I get:
      PASS Jun 14 10:58:01 TUNNELBROKER [2a02:348:82:cb69::1]:46774 [2001:470:27:dd5::2]:21 TCP:S

      But packet is still not forwarded to the client.  (as seen with wireshark)

      I could not get the forwarding working and autocreated rules is not working (blocks traffic for the NAT:ed destination).

      I have also tested to change the "Redirect target IP" between 2001:470:28:dd5:39cf:c6b0:4657:c4ed
      and 2001:470:28:dd5:9d10:2041:bd1b:6e7c but same result.

      Also tried to define the "Redirect target IP" to the Link-Local address of the client "fe80::39cf:c6b0:4657:c4ed" but still same result.

      I totally scratch my head now and is running out of ideas.

      One interesting observation is that the autocreated rule has a Destination with the IP as "Single host or alias" BUT with a /32 mask.
      And that is not changeable as this is a NAT/Rule combination so it is grayed.

      Another drawback is also that the rule auto-created is set to default IPv4 only even if the IP entered in the "Redirect target IP" is an IPv6 notation.
      Please add a check to change it to IPv6 if a v6 IP-format is detected. (Feature-request)

      Best regards
      Dan Lundqvist
      Stockholm, Sweden
      UPDATE 2012-06-14: Have tested Packet Capture on both TUNNELBROKER interface (port21) and on LAN interface (port 21)
      I see the incoming  SYN packets to pfSense on the BROKER-ifc but nothing on the outgoing LAN interface so the packet is blocked
      even if the Firewall entry says "PASS". It seems to be routed to cyberspace and not exiting on LAN-ifc.

      1 Reply Last reply Reply Quote 0
      • johnpozJ
        johnpoz LAYER 8 Global Moderator
        last edited by

        You don't nat or port foward IPv6 addresses – you allow or not allow via simple firewall rule.

        One of the big advantages of ipv6 huge amount of space is everyone can have a /64 public IP that is globally routable on the net.

        if you want 21 to one of your ipv6 boxes on your routed /64 from he, then just allow that protocol through.

        So for example - I allow ntp into my timeserver for pool.ntp access, and icmp to any box on my /64

        Also if you having issues with IPv6 getting back out, make sure you have a lan rule that allows your IPv6 traffic, I modify the default rule a bit to say * for source.  Just look at the IPv6 lan rule - those other rules are for testing proxy access from one specific box, etc.  And then the default ipv4 lan rule.. I open up the lan source to allow for openvpn stuff.

        ipv6firewallrule.jpg
        ipv6firewallrule.jpg_thumb
        lanrules.jpg
        lanrules.jpg_thumb

        An intelligent man is sometimes forced to be drunk to spend time with his fools
        If you get confused: Listen to the Music Play
        Please don't Chat/PM me for help, unless mod related
        SG-4860 24.11 | Lab VMs 2.8, 24.11

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

          Hello John,

          Thanks so much for clearing out this mind-block from my side.
          I'm so used to the "old way" that I don't see the forest due to all trees. :-)

          So elegant and straight forward.  I give it a try.

          Best regards
          Dan Lundqvist

          UPDATE: Worked like a charm… :-)  Thanks for pointing my mind in the right direction.

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