This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Divide large IPv6 network into subnets

Hi there,

maybe the answer to my questions is quite obvious and I just don't see the forest for the trees...
But I currently don't have a clue and I don't even know how to search for the answer.
So please also bear with me if the question was already answered thousands of times and I didn't find it.

My provider provides me with an IPv6 network 2001:db8:1::/48.

My Sophos UTM has the IP address 2001:db8:1::2 on its Internet interface (eth0). The provider's endpoint has the address 2001:db8:1::1.

From an IPv6-enabled host in the Internet, I am able to reach both 2001:db8:1::1 and 2001:db8:1::2. So far so good.

As this is a very large network, I would like to split it up into several smaller ones. I am unsure how to accomplish that. (My provider did not delegate a separate subnet which I could use...)

So I thought, I assign the network 2001:db8:1:100::/64 to eth1 with eth1 having the IP address 2001:db8:1:100::1 and a client in that network having 2001:db8:1:100::2.

I thought, the UTM should receive all the network packets for the /48 subnet and it can decide to which interface the packets are to be forwarded to, i.e. all packets in the network 2001:db8:1:100::/64 should be forwarded to eth1, as the firewall knows this subnet. (Although now, there are two network interfaces in the same network - at least as eth0 understands the networks. The eth1's address (and whole address space) is in the same network where also eth0's IP address lies... So somehow, this seems wrong...)

I cannot reach either 2001:db8:1:100::1 or 2001:db8:1:100::2. Does anyone have an idea what I am doing wrong?

Or isn't that possible at all with the IP address and subnet given from my provider? (But why does my provider give me a /48 network, then?)

Any help would be highly appreciated.

Best regards


This thread was automatically locked due to age.
  • It's my understanding that with ipv6, there's no need for NAT.  However, you still need to establish firewall rules to allow the traffic in.

    So something like internet ---> 2001:db8:1:100::/64.  For ports, whatever ports you deem necessary.  For starters you can just allow ALL, then fine tune once you've confirmed that works. Internet network_port2 below refers to the entire network (not address or broadcast). The screenshot below is something I used for brief testing few moments ago. You'd want to narrow it down to a specific destination host (server?).

    This might shed some more light on ipv6 subnets -

    Most providers offer must smaller subnets, /56. With att I get /60 which allows for just 16 /64 subnets. You get up to up 65536.

    How are you testing if the address is reachable?  I used . Firewall log recorded attempts to reach the various ports I tested.

  • Hi Jay Jay,

    thank you for your answer. I am sorry, I forgot to mention that I already have a firewall rule in place allowing me to connect to 2001:db8:1:100::2 on port 443.

    But that doesn't work. It's not even possible to receive ping replys from that host.

    How did you configure the network interfaces?

    Does the Internet interface have to be configured as 2001:db8:1::1/48 or rather as 2001:db8:1::1/64 to prevent overlapping with the network on my internal interface? (But that doesn't make sense to me, either...)

    I also forgot to mention, that I have enabled all the ICMP options. Nothing should block ICMP traffic.

    Outgoing ping packets are working fine.

    Best regards Tom

  • What is the client on the lan side?  Windows?  Is the windows firewall active?  If so, did you make a rule for the inbound traffic?  Or just disable it entirely during testing.

    I don't think it matters how the wan interface is configured, more so the lan so UTM knows where to direct the traffic bound for that particular subnet. On mine, wan is configured as x:y:z:1::1/64, lan x:y:z:2::1/64.

    Show a pic of your firewall rule.

  • I'll get a pic of the rule as soon as I am back in the office.
    But could it be a missing rule if even ICMP packets are blocked?

    We have a difference in our interface configurations.
    My wan is configured as x:y:z::1/48.
    My lan is configured as x:y:z:1::1/64.

    The client on the lan side is a Linux client. Server firewall is off.

  • I was able to get a screenshot from remote:

    Please note that this is a German system.

    "Quellen" means "Sources",
    "Dienste" means "Services",
    "Ziele" means "Destinations",
    "Aktion" means "Action",
    "Zulassen" means "Allow"
    "Kommentar" means "Comment"
    "Erweitert" means "Advanced"

    I've now even allowed the whole network (called "IP6-DMZ"), but still no luck.

    I can verify that when pinging the external host from the internal host, the packets arrive at the external host (ping-request) and the external hosts sends a ping-reply to originating IPv6 address, but these packets never arrive.

    Now I found out one more strange phenomenon:
    I can ping the firewall's IPv6 LAN address from the client on the LAN.
    I can also ping the firewall's IPv6 WAN address from the client on the LAN.
    I can NOT ping the provider's IPv6 address.

    (Again the IP addresses:

    Whole block: x:y:z::/48
    IP address of provider x:y:z::1
    WAN address of UTM: x:y:z::2 (interface configured as x:y:z::2/48, [but also tried x:y:z::2/64 with no difference])
    LAN address of UTM: x:y:z:100::1 (interface configured as x:y:z:100::1/64)
    address of host on the LAN: x:y:z:100::2)

    From the client on the LAN (x:y:z:100::2):
    ping x:y:z:100::2 --> OK
    ping x:y:z:100::1 --> OK
    ping x:y:z::2 --> OK
    ping x:y:z::1 --> NOT OK!

    I think that narrows down the issue, although I am not really sure what to do with this new information ;-)

  • Any change if you change services to ANY?

    In my testing, I didn't try to ping as I didn't have any external ipv6 source to ping from).  What I did test was to determine if a particular port was open. I saw the inbound attempts in the firewall log referencing the defined rule.

    I suppose it would be worth looking at your firewall log to see if the attempt is even registering.

  • sorry for my late reply.

    Setting the protocol to ANY doesn't work either.

    I am really stuck now. I begin to think that it isn't even possible to work with just one network without having an additional routed network from the ISP.

    But in your side it seems to work.

    And why should the ISP assign a /48 network to me if I cannot use it on any way?

  • I just noticed on your pic above, position 355. Recall rules are processed top to bottom. If something earlier is blocking, then the packet will never get processed by the later rule.

    In general (think I read that here¿?).  You want your most specific/granular rules up top, general ones at the bottom. Generally speaking :).

  • Thanks for your reply!

    I understand that you expect that the traffic was blocked by another rule with a lower number?
    Unfortunately, this is not the case.
    It doesn't matter where I place the rule. The ping never works.

    But I still have another question which I don't really understand.

    I have two networks on my two firewall ports:

    - network 2001:db8:1::/48 on eth0
    - network 2001:db8:1:100::/64 on eth1

    But the network on eth0 (2001:db8:1::/48) INCLUDES the network on eth1 (2001:db8:1:100::/64), which basically means that the network 2001:db8:1:100::/64 is available on both eth0 and eth1. How does the routing work when there's a network on two network interfaces?

    This is the main part I do not understand. All the rules and so on seem to be pretty clear to me. I think I have a more fundamental problem...

    But I am not sure how the UTM has to be configured in such a scenario. (Currently completely besides all the firewall rules and so on.)

  • Eth0 is wan, eth1 is lane?

    The /48 is the prefix delegation. You then can carve up the 16 bits (64-48) however you choose. 

    When I first started with ipv6, I made sure outbound worked properly before focusing on anything inbound.

    Got to, see what it reveals about your ipv6 address(es). That might shed some light on where to look.

    Both of the ipv6 addresses match below and are the same as reported by windows as my ipv6 "temporary address"