Navigation

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

    Static IPv6 problems

    IPv6
    6
    23
    8389
    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.
    • H
      henrik242 last edited by

      We just got a /48 from our ISP, but I'm having problems getting IPv6 connection from my computer.  We're running pfSense 2.1-BETA0 (i386)
      built on Tue Jul 3 17:55:18 EDT 2012.

      I've set the WAN gateway to aaaa:bbbb:cccc::1/48, and the WAN interface address to aaaa:bbbb:cccc::2/48.  After that I set the LAN interface address to aaaa:bbbb:cccc::3/48 and set DHCPv6 Server/RA » LAN » Router Advertisments to Unmanaged.

      I see that I get a IPv6 address on my computer (MacOSX 10.8) (I don't know why the utun interfaces are there):

      $ ifconfig
[...]
en1: flags=8863 <up,broadcast,smart,running,simplex,multicast>mtu 1500
	ether 58:b0:35:7b:95:6c 
	inet6 fe80::5ab0:35ff:fe7b:956c%en1 prefixlen 64 scopeid 0x5 
	inet 10.110.0.13 netmask 0xfffffe00 broadcast 10.110.1.255
	inet6 aaaa:bbbb:cccc::5ab0:35ff:fe7b:956c prefixlen 64 autoconf 
	inet6 aaaa:bbbb:cccc::2c93:3446:e94f:3756 prefixlen 64 autoconf temporary 
	media: autoselect
	status: active
[...]
utun0: flags=8051 <up,pointopoint,running,multicast>mtu 1380
	inet6 fe80::c8f1:2a41:5e62:a011%utun0 prefixlen 64 scopeid 0x9 
	inet6 fd7f:2f92:1d5d:cf03:c8f1:2a41:5e62:a011 prefixlen 64 
utun1: flags=8051 <up,pointopoint,running,multicast>mtu 1380
	inet6 fe80::c8f1:2a41:5e62:a011%utun1 prefixlen 64 scopeid 0xa 
	inet6 fd00:6587:52d7:857:c8f1:2a41:5e62:a011 prefixlen 64</up,pointopoint,running,multicast></up,pointopoint,running,multicast></up,broadcast,smart,running,simplex,multicast>

      I'm unable to ping the LAN and WAN interfaces, as well as outside addresses:

      $ ping6 aaaa:bbbb:cccc::1
PING6(56=40+8+8 bytes) aaaa:bbbb:cccc::5ab0:35ff:fe7b:956c --> aaaa:bbbb:cccc::1
^C
--- aaaa:bbbb:cccc::1 ping6 statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

      Also, I'm unable to ping external IPv6 addresses when I'm logged into the pfSense box via SSH.

      Any ideas what I'm doing wrong?

      1 Reply Last reply Reply Quote 0
      • P
        podilarius last edited by

        First thing is that you might not be in the same subnet. you are giving a /48. If you set to unmanaged, your computers are most likely getting a /64 that is in a different subnet. Try setting up LAN in the same /64 as the WAN, or change the dhcp6 settings to give out the /48 subnet mask.

        1 Reply Last reply Reply Quote 0
        • H
          henrik242 last edited by

          Hmm.  I tried enabling the DHCPv6 Server on the LAN interface, and set the range to aaaa:bbbb:cccc:0:0:0:0:ff » aaaa:bbbb:cccc:0:0:0:0:ffff.  I also set the RA to Managed.

          No success, and I don't get a related IPv6 address on my computer anymore:

          $ ifconfig
[...]
en1: flags=8863 <up,broadcast,smart,running,simplex,multicast>mtu 1500
	ether 58:b0:35:7b:95:6c 
	inet6 fe80::5ab0:35ff:fe7b:956c%en1 prefixlen 64 scopeid 0x5 
	inet 10.110.0.13 netmask 0xfffffe00 broadcast 10.110.1.255
	media: autoselect
	status: active
[...]
utun0: flags=8051 <up,pointopoint,running,multicast>mtu 1380
	inet6 fe80::c8f1:2a41:5e62:a011%utun0 prefixlen 64 scopeid 0x9 
	inet6 fd7f:2f92:1d5d:cf03:c8f1:2a41:5e62:a011 prefixlen 64 
utun1: flags=8051 <up,pointopoint,running,multicast>mtu 1380
	inet6 fe80::c8f1:2a41:5e62:a011%utun1 prefixlen 64 scopeid 0xa 
	inet6 fd00:6587:52d7:857:c8f1:2a41:5e62:a011 prefixlen 64</up,pointopoint,running,multicast></up,pointopoint,running,multicast></up,broadcast,smart,running,simplex,multicast>
          1 Reply Last reply Reply Quote 0
          • P
            podilarius last edited by

            iirc .. you need to make the LAN into a /64 so that unmanaged and managed RA works correctly. At least, that is the only way i got mine to work. With at /48, you have 65535 separate /64 subnet you can use. I have tried to figure that out myself to be honest. Also, you will probably have issue getting to the internet as the return traffic will stay on the WAN and not pass through. Since the LAN IPs are in the same subnet as the WAN, the WAN will not route inward. It will expect the IP to be on the same switch as the WAN.
            I had to have my ISP create a /64 WAN gateway and go with a routed solution. If pfSense is supposed to do otherwise, then I could not get it to work.
            I guess you could setup a NPt, but I am not experienced enough with that to know what will happen.

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

              You don't put the same subnet on WAN and LAN. You must have one /64 (or /126 maybe, depends on your provider) for WAN, and a separate /48 for your internal networks that's routed to your WAN. Of which you should use only one /64 per broadcast domain.

              1 Reply Last reply Reply Quote 0
              • H
                henrik242 last edited by

                @cmb:

                You don't put the same subnet on WAN and LAN. You must have one /64 (or /126 maybe, depends on your provider) for WAN, and a separate /48 for your internal networks that's routed to your WAN. Of which you should use only one /64 per broadcast domain.

                Our provider has given us a single aaaa:bbbb:cccc::/48 network with the aaaa:bbbb:cccc::1/48 gateway.  Can I use this to configure the LAN and WAN networks with pfSense, or do I need additional configuration from our provider?  Is there a way to solve this without involving them?

                1 Reply Last reply Reply Quote 0
                • P
                  podilarius last edited by

                  I don't know, perhaps a bridge or a NATed solution.

                  1 Reply Last reply Reply Quote 0
                  • H
                    henrik242 last edited by

                    @podilarius:

                    I don't know, perhaps a bridge or a NATed solution.

                    But then I wouldn't get a public IP, right?  (At least not in the NATed solution)

                    1 Reply Last reply Reply Quote 0
                    • P
                      podilarius last edited by

                      You would not have a public ip on the LAN in a NATed solution. I would work with your ISP to create a routed solution. My 2 ISPs worked with me to create the routes as necessary. They even created a /64 they are going to use for all their customers WANs.

                      1 Reply Last reply Reply Quote 0
                      • D
                        databeestje last edited by

                        Note: Some ISPs will allocate you a /48 and assign the 1st 0000 subnet to the directly connected interface. They will likely also have a static route that points the /48 to the ::2 address. This is what your downstream router needs to be addressed as.

                        You configure the 1st /64 you got allocated on the WAN.
                        You configure the <prefix>:0::/2 on the WAN, /64 or /126 does not specifically matter.
                        You configure a network out of <prefix>other then 0 on the LAN, for example give the LAN address <prefix>:1::1/64
                        Go to the DHCPv6 server page, select assisted, enable DHCPv6 server too.

                        All clients should now pick this up on the LAN in about 10 seconds.

                        If you have more interfaces you can configure other <prefix>:n::/64 networks locally. 2-ffff.
                        If you have a internal router, create a static route for <prefix>:nn00::/56 to this router so you repeat the steps above.

                        Note 2: this has nothing to do with pfSense perse, this is basic subnetting 101. Let the NAT go folks. It isn't there.</prefix></prefix></prefix></prefix></prefix>

                        1 Reply Last reply Reply Quote 0
                        • P
                          podilarius last edited by

                          @databeestje:

                          Note 2: this has nothing to do with pfSense perse, this is basic subnetting 101. Let the NAT go folks. It isn't there.

                          Preach it!!! NAT should go the way of the Dodo. There is more than enough addresses in IPv6.

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

                            @databeestje:

                            Note: Some ISPs will allocate you a /48 and assign the 1st 0000 subnet to the directly connected interface. They will likely also have a static route that points the /48 to the ::2 address. This is what your downstream router needs to be addressed as.

                            This is how it should be if you have a single /48. I suspect (and hope!) the OP is misunderstanding what his provider is giving him.

                            If not, and it truly is a /48 assigned to the ISP's router and you're supposed to somehow use that in a practical fashion, your ISP has completely failed at the most basic of IPv6 service provider concepts, and needs to give you a proper routed setup.

                            1 Reply Last reply Reply Quote 0
                            • P
                              podilarius last edited by

                              Lol … my ISP gave me a /48 with a gateway and that was it. I had to have them setup the /64 for me to be into and then route all the /48 to that new /64 address. They failed at subnetting 101 (at least at first).

                              1 Reply Last reply Reply Quote 0
                              • H
                                henrik242 last edited by

                                So, I've been trying to fit the WAN on a /64 and the LAN on another /64 within our /48, without involving our ISP.  Current test setup:

                                WAN gateway 1111:2222:3333::1/48
                                WAN interface (em3) 1111:2222:3333::2/64
                                LAN interface (em1) 1111:2222:3333:1::1/64
                                Test client on LAN 1111:2222:3333:1::abcd/64

                                netstat -r shows:

                                Destination         Gateway            Flags      Netif Expire
default             1111:2222:3333::1  UGS         em3
localhost           localhost          UH          lo0
1111:2222:3333::    link#4             U           em3
1111:2222:3333::2   link#4             UHS         lo0
1111:2222:3333:1::  link#2             U           em1
1111:2222:3333:1::1 link#2             UHS         lo0

                                I can ping the WAN gateway from the router. From the test client I can ping the LAN & WAN interfaces, but not the WAN gateway.

                                If I try to add an explicit route, I get an error:

                                $ route add -inet6 -net 1111:2222:3333:1::/64 1111:2222:3333::2
route: writing to routing socket: File exists
add net 1111:2222:3333:1::/64: gateway 1111:2222:3333::2: route already in table
                                1 Reply Last reply Reply Quote 0
                                • P
                                  podilarius last edited by

                                  You still have the same problem. The ISP is not routing anything to 1111:2222:3333::2/64. To the ISP, that address should be on the same interface as WAN hence no routing.
                                  I think you are going to have to involve your ISP.
                                  I have not tried working with NPt, but you might be able to use that to translate 1111:2222:3333:1::2/64 to 1111:2222:3333:2::2/64 (LAN). This is of course not ideal.

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

                                    @henrik242:

                                    So, I've been trying to fit the WAN on a /64 and the LAN on another /64 within our /48, without involving our ISP.

                                    Which is impossible. There isn't a way around this without getting the ISP to give you a proper v6 setup, which you don't currently have.

                                    1 Reply Last reply Reply Quote 0
                                    • H
                                      henrik242 last edited by

                                      @cmb:

                                      @henrik242:

                                      So, I've been trying to fit the WAN on a /64 and the LAN on another /64 within our /48, without involving our ISP.

                                      Which is impossible. There isn't a way around this without getting the ISP to give you a proper v6 setup, which you don't currently have.

                                      But, since they are routing the whole /48 to our network interface, shouldn't I be able to handle the subnetting on our side?

                                      Anyway, sorry for being dim, but what exactly do I ask the ISP to do?  Have them drop the /48 routing and instead route 1111:2222:3333:0::/64 and 1111:2222:3333:1::/64 to our interface?

                                      1 Reply Last reply Reply Quote 0
                                      • P
                                        podilarius last edited by

                                        I would not look at this as routing to an interface. Instead, they are routing to their gateway. And since it expects your entire /48 on that same gateway it does not forward the traffic to anything.  This is why a bridge would work. If you don't wanto involve the ISP, that is going to be the only way. That would be a problem if your are dual stacking. It won't be feasible in that situation.

                                        You are going to ask them to help build a routed solution.  Not sure but one of my ISPs gave me a /56 but they reserved the xxxx::0::1-3 addresses and setup a route for each /64 that makes up the /56 to ::4( my wan address on pfsense ). My other ISP like I said earlier gave us /48 and they had to create a /64 for my wan so they cod route the entire /48 to it. So basically you need to ask them to setup you up with 2 subnets so that you can route one to the other.

                                        1 Reply Last reply Reply Quote 0
                                        • I
                                          itsgc last edited by

                                          @podilarius:

                                          My other ISP like I said earlier gave us /48 and they had to create a /64 for my wan so they cod route the entire /48 to it. So basically you need to ask them to setup you up with 2 subnets so that you can route one to the other.

                                          Hi forum, first time user here. I have been trying to help OP over at serverfault.com with this issue. I am a junior network engineer and i enjoy a good puzzle. Am i mistaken in believing OP's setup is VERY VERY unusual? I set up several (20+) customers with allocated subnets (both ipv4 and ipv6) and they were always point-to-point connection for wan + routed subnet. I apologize if i created confusion into OP's mind but i always assumed ISP gave him a routed solution (which is standard around here, Italy). Not being familiar with pfSense's lingo (Cisco guy here) didn't help either.

                                          I now agree that the quickest fix to this is to just ask a subnet for its point-to-point link (wan) and to route the whole /48 directly to him so that he can do with it as he pleases.

                                          How common is OP's current setup? i'd hate to find myself in the same situation.

                                          1 Reply Last reply Reply Quote 0
                                          • P
                                            podilarius last edited by

                                            I think that kind of setup is going to be the norm in IPv6. There are more than enough addresses to do that. Personally, I would like ISPs handing out either /124 or /112 to be used for WAN and setting the gateway to xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxx1 and routing the customer's subnet to xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxx2 or routing multiple subnets to different WAN IPs within the range. I just don't think you need to waste an entire /64 just for a routing subnet. At least for those that are not running BGP or similar.

                                            1 Reply Last reply Reply Quote 0
                                            • I
                                              itsgc last edited by

                                              Good writeup on the subject:
                                              http://etherealmind.com/allocating-64-wasteful-ipv6-not/

                                              Subnetting deeper than /64 breaks a number of automatic mechanisms in IPv6 and it's not really needed :p

                                              1 Reply Last reply Reply Quote 0
                                              • P
                                                podilarius last edited by

                                                I agree that we will probably regret handing out all the /64 bit subnets at some point.

                                                However, some network administrators have used prefixes longer than /64 for links connecting routers, usually just two routers on a point-to-point link. On links where all the addresses are assigned by manual configuration, and all nodes on the link are routers (not end hosts) that are known by the network administrators do not need

                                                I agree with this also, that we should probably be using longer prefixes for inter-router communication as in between an ISP and customer router (pfsense in my case) :). There is no need for automatic configuration or alot of the other feature as this is manually setup. But for home use, /64 does make sense as that will be mostly autoconfigs. Then, how do you setup FW services, as a bridge because a routed solution doesn't make much sense (where you are wasting 2 /64 to get access to at most 100 devices (and I am being generous for home users), neither does a NATed solution. You could even use 2 /112 in a routed solution (if it didn't break anything). That would be more than enough for any home user. IPv6 has been around long enough to have already fixed autoconfig without the /64. Hopefully that will be fixed soon enough. Enough of the soap box.

                                                What are ISPs like comcast doing for IPv6 customers in the residential market?

                                                1 Reply Last reply Reply Quote 0
                                                • B
                                                  bardelot last edited by

                                                  What are ISPs like comcast doing for IPv6 customers in the residential market?

                                                  They use DHCPv6 with a /128 on the WAN side and a /64 for the LAN.

                                                  [1] http://forum.pfsense.org/index.php?topic=49575.0
                                                  [2] http://ipvsix.me/?p=220

                                                  1 Reply Last reply Reply Quote 0
                                                  • First post
                                                    Last post

                                                  Products

                                                  • Platform Overview
                                                  • TNSR
                                                  • pfSense
                                                  • Appliances

                                                  Services

                                                  • Training
                                                  • Professional Services

                                                  Support

                                                  • Subscription Plans
                                                  • Contact Support
                                                  • Product Lifecycle
                                                  • Documentation

                                                  News

                                                  • Media Coverage
                                                  • Press
                                                  • Events

                                                  Resources

                                                  • Blog
                                                  • FAQ
                                                  • Find a Partner
                                                  • Resource Library
                                                  • Security Information

                                                  Company

                                                  • About Us
                                                  • Careers
                                                  • Partners
                                                  • Contact Us
                                                  • Legal
                                                  Our Mission

                                                  We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                                                  Subscribe to our Newsletter

                                                  Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                                                  © 2021 Rubicon Communications, LLC | Privacy Policy