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

    Router advertisement not sending default gateway

    Scheduled Pinned Locked Moved IPv6
    23 Posts 4 Posters 529 Views 4 Watching
    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.
    • E Offline
      Euroguy @patient0
      last edited by

      @patient0
      This is a linux vm running latest openSuSE doing DHCP:

      313127d4-3034-4d66-ac5f-be94c1114359-image.png

      Meanwhile, it seems some IP address leases were in fact working:
      They weren't last night but seems to have kicked in sometimes later.

      a0baca10-75c8-47f8-a590-16b44bccd439-image.png

      They are all for Windows Server VM's running on Virtual NIC's.
      Here they can be seen in the DNS server:
      31387948-d34e-4ff8-8d17-f1563be9a1fe-image.png

      1 Reply Last reply Reply Quote 0
      • P Offline
        pst @Euroguy
        last edited by

        @Euroguy said in Router advertisement not sending default gateway:

        Switched to use DHCP on the pfsense, and IPv6 leases don't work on KEA at all (it gets permission denied sending message().

        I still recommend you use KEA, as makes it easier to support you :) Debugging permission denied should be fairly simple (...)

        You seem to have gotten the DHCPv6 Tracking on WAN working, prefix on LAN DHCPv6 looking good.

        It is sometimes difficult "to see the forest for all the trees", so I suggest testing the setup in smaller steps, starting with just the pfsense, and a LAN with one client active. Running DNS on the pfsense also simplifies matters.

        Is pfsense a bare metal machine, or is it a virtual setup? (==complication)

        pfsense does it wierdly somehow, from a windows perspective, so windows clients never accept the address,

        I run windows clients (Win10 and Win10 VMs) as well as Linux VMs and I have not noticed anything weird going on. Are the windows clients VMs or regular machines? Are they configured with default DHCP configs or are there legacy configurations from your previous (=current setup)?

        Switched to use DHCP on the pfsense,

        this suggests you ran DHCP elsewhere previously?

        Tried to run KEA and ISC on Debian, and there DHCP6 works, and ISC on openSuSE works as well.

        So, what you are saying is that a windows client can get an address from a non-pfsense DHCP server, but not from the pfsense running the dhcp server?

        Again, I suggest turning off/disconnecting everything that complicates the debugging of the pfsense setup (suggestion above). Once the basic setup of pfsense works it should be easy to hook up the rest of your network...

        E 1 Reply Last reply Reply Quote 0
        • E Offline
          Euroguy @pst
          last edited by

          @pst
          I have two AD DC machines running DNS etc, and one of them ran DHCP.

          But after nothing worked and I got into trouble, I wanted to know if the problem was due to me running DHCP on a separate machine, so switched to running it on the pfSense machine.
          And that didn't work at all.

          Then i tested an debian and an open suse (VMs) I had.
          Installed and confed DHCP on both of them to test.
          Ran flawlessly and without a hitch (once I got them up and running, conf was a bit of a mess)

          pfsense is running on a
          0d968c3a-3133-4842-9ed2-92053d1e796f-image.png

          I had saved the old version (saved the disk) so just reconnected it and fired it up.

          It is running 2.5.2.
          And immedietly I got working RA:s
          d12e01d4-5613-4505-8365-73f129c53211-image.png

          And RA config is the same it seems:
          85fcec59-587f-45b2-b613-61c4ff3da7d2-image.png

          I'll try to reinstall 2.8 and see if I can get that to work as a baseline.
          Else I think I'll settle for 2.7.2 for now.

          E 1 Reply Last reply Reply Quote 0
          • E Offline
            Euroguy @Euroguy
            last edited by

            @Euroguy So, followup after a reinstallation of the system

            Short answer is, things now seem to work.
            Not sure why RA or DHCP did not work before.
            Only thing I did different now vs before is I started on LAN IPv6 to track interface and never tried to get static addressing to work

            So likely something in that config blockingly persisted/wasn't cleared as it should have.
            Some baby bugs like that is to be expeceted for a gold release I guess.

            Still have some things to add on, like OpenVPN, dyn dns och letsencrypt ACME certs but seems the baseline seems more stable now at least.

            I get both DHCP4 and 6 clients with leases now (although status of lease seems broken, always showing black down arrow even though lease is active and remote machine is up and active:
            6ad7637c-7979-4b0b-8d7a-3cfd1d1a1ba6-image.png

            Thansk @patient0 and @pst for your patient help.

            P 1 Reply Last reply Reply Quote 0
            • E Offline
              Euroguy
              last edited by

              A few things noted, that I also noted earlier, that might help others:

              1. General setup allows changing of LAN and WAN addresses during the grub setup.
                Setting a static ipv4 adress other than 192.168.1.1 is however ignored and the system starts up with 192.168.1.1 after setup is done. So a post setup change of LAN address is needed.

              2. DHCP6 server fails as DHCP requests / Discovery is done on fe80::/10 and that is not considered to be LAN it seems. I had to add a LAN allow rule for fe80::10 to ff02::/16 like this for DHCP6 to work:
                e98b2093-2534-4c7e-9c09-6d54251d537d-image.png

              1 Reply Last reply Reply Quote 0
              • JKnottJ Offline
                JKnott
                last edited by

                Why are you using static config on IPv6? Normally, you'd use track interface.

                Why are you configuring unique local addresses, instead of using those provided by your ISP? If you want to add ULA, you do it on the Router Advertisement page.

                PfSense running on Qotom mini PC
                i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
                UniFi AC-Lite access point

                I haven't lost my mind. It's around here...somewhere...

                E 1 Reply Last reply Reply Quote 0
                • E Offline
                  Euroguy @JKnott
                  last edited by

                  @JKnott

                  Well.
                  My first experience with IPv6 was static IP-addresses and on Juniper FW on our office location and Cisco ASA on our server location way back when, when only IPv4 was mostly in use and NAT was the boss. And the servers were all Windows in AD domains.

                  Both of them support NAT of both IPv4 and IPv6 and it's just the way it was setup, due to these. Tbh, I don't think either of them supported anything else at the time.
                  And also, we got /64 addresses on both locations.

                  I could have done a subnet delegation from /64 to /80 or something but at that time,
                  But on Windows it's kinda preferred to have /64 nets, so difficult to split them.
                  But with static private ip addresses you have that

                  1. It's just like IPv4.
                  2. It's super easy to do 1:1 NAT and publishing/mapping.
                  3. Single IPv6 addresses just like on IPv4 internally.

                  To be honest I don't even know (I am sure there is a way) how to publish an internal server with Track Network to a public subset internally as all addresses are temporary, being renewes whenever the ISP recycles the DCHP leases on the WAN side.

                  Now, while one of the points of IPv6 is to be able to use same public IPv6 as well as externally, for some people used to IPv4, it's just easier to do it the same for IPv6 as that is how it's always been done in the firewall world in traditional firewalls.

                  However don't really work with those kinda things for a while now so not really up to date with how Cisco, Juniper or Fortinet does things, so can't say for sure if this is still the default mode.

                  But anyway, that's why.

                  JKnottJ 1 Reply Last reply Reply Quote 0
                  • JKnottJ Offline
                    JKnott @Euroguy
                    last edited by

                    @Euroguy said in Router advertisement not sending default gateway:

                    It's just like IPv4.
                    It's super easy to do 1:1 NAT and publishing/mapping.
                    Single IPv6 addresses just like on IPv4 internally.

                    You're following bad habits you learned with IPv4 and it's address shortage. What does your ISP provide? If something bigger than a /64, you split that into individual /64s for your network. Do not split a /64 into /80 etc., as that will break things.

                    I get a /56 from my ISP, which I can split into 256 /64s.

                    PfSense running on Qotom mini PC
                    i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
                    UniFi AC-Lite access point

                    I haven't lost my mind. It's around here...somewhere...

                    1 Reply Last reply Reply Quote 0
                    • P Offline
                      pst @Euroguy
                      last edited by pst

                      @Euroguy said in Router advertisement not sending default gateway:

                      So, followup after a reinstallation of the system

                      Short answer is, things now seem to work.

                      Glad to see you got it up and running :)

                      I get both DHCP4 and 6 clients with leases now (although status of lease seems broken, always showing black down arrow even though lease is active and remote machine is up and active

                      I see that from time to time too. I think there are some timers that you can tweak (can't recall which ones though) that determines how long it takes without a "sign of life" before the client is marked as offline. For IPv4 there's an ARP timer ... and for v6 it should be an equivalent NDP timer. Can be set in System / Advanced / Tunables once you find out what they are called :)

                      DHCP6 server fails as DHCP requests / Discovery is done on fe80::/10 and that is not considered to be LAN it seems. I had to add a LAN allow rule for fe80::10 to ff02::/16 like this for DHCP6 to work:
                      e98b2093-2534-4c7e-9c09-6d54251d537d-image.png

                      That rule shouldn't be needed, it is part of the automatic rule set added by pfSense. I get those by means of pfSense magic: (check in /tmp/rules.debug)

                      pass in  quick on $WAN proto udp from fe80::/10 port = 546 to fe80::/10 port = 546 ridentifier 1000000463 label "allow dhcpv6 client in WAN"
pass  quick on $LAN inet6 proto udp from fe80::/10 to fe80::/10 port = 546 ridentifier 1000002551 label "allow access to DHCPv6 server"
pass  quick on $LAN inet6 proto udp from fe80::/10 to ff02::/16 port = 546 ridentifier 1000002552 label "allow access to DHCPv6 server"
pass  quick on $LAN inet6 proto udp from fe80::/10 to ff02::/16 port = 547 ridentifier 1000002553 label "allow access to DHCPv6 server"
pass  quick on $LAN inet6 proto udp from ff02::/16 to fe80::/10 port = 547 ridentifier 1000002554 label "allow access to DHCPv6 server"
<snip>

                      Update:
                      the timer tweak I used a long time ago was

                      net.link.ether.inet.max_age=60

                      which make the cached ARP-entry lifetime 60 seconds, I wanted clients to go offline faster. Default is 1200s. See https://man.freebsd.org/cgi/man.cgi?query=arp&sektion=4

                      24319ba3-b5d5-4add-b251-9993249ff5a6-image.png

                      E 2 Replies Last reply Reply Quote 0
                      • E Offline
                        Euroguy @pst
                        last edited by

                        @pst said in Router advertisement not sending default gateway:

                        DHCP6 server fails as DHCP requests / Discovery is done on fe80::/10 and that is not considered to be LAN it seems. I had to add a LAN allow rule for fe80::10 to ff02::/16 like this for DHCP6 to work:
                        e98b2093-2534-4c7e-9c09-6d54251d537d-image.png

                        That rule shouldn't be needed, it is part of the automatic rule set added by pfSense. I get those by means of pfSense magic: (check in /tmp/rules.debug)

                        It is needed for me atleast.
                        I disabled it and did a release / renew, and immediately deny for rule 1000000105 in my firewall log:

                        7aa13bff-b5a2-4daf-8f39-958a933bacc6-image.png

                        1 Reply Last reply Reply Quote 0
                        • E Offline
                          Euroguy @pst
                          last edited by

                          @pst said in Router advertisement not sending default gateway:

                          That rule shouldn't be needed, it is part of the automatic rule set added by pfSense. I get those by means of pfSense magic: (check in /tmp/rules.debug)

                          here are some snips from that file (I can see ICMP added automatically, but not UDP):

                          • Allow only bare essential icmpv6 packets (NS, NA, and RA, echoreq, echorep)

                          pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type {129,133,134,135,136} ridentifier 1000000108 keep state

                          pass out quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type {129,133,134,135,136} ridentifier 1000000109 keep state

                          pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type {128,133,134,135,136} ridentifier 1000000110 keep state

                          pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type {128,133,134,135,136} ridentifier 1000000111 keep state

                          pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type {128,133,134,135,136} ridentifier 1000000112 keep state

                          pass in quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type {128,133,134,135,136} ridentifier 1000000113 keep state

                          We use the mighty pf, we cannot be fooled.

                          block log quick inet proto { tcp, udp } from any port = 0 to any ridentifier 1000000114 label "Block traffic from port 0"

                          block log quick inet proto { tcp, udp } from any to any port = 0 ridentifier 1000000115 label "Block traffic to port 0"

                          block log quick inet6 proto { tcp, udp } from any port = 0 to any ridentifier 1000000116 label "Block traffic from port 0"

                          block log quick inet6 proto { tcp, udp } from any to any port = 0 ridentifier 1000000117 label "Block traffic to port 0"

                          Furthermore I can see that I have autoadded config rules for DHCP4 and DHCP6 here:

                          • allow access to DHCP server on LAN

                          pass in quick on $LAN proto udp from any port = 68 to 255.255.255.255 port = 67 ridentifier 1000002541 label "allow access to DHCP server"

                          pass in quick on $LAN proto udp from any port = 68 to 192.168.2.3 port = 67 ridentifier 1000002542 label "allow access to DHCP server"

                          pass out quick on $LAN proto udp from 192.168.2.3 port = 67 to any port = 68 ridentifier 1000002543 label "allow access to DHCP server"

                          • allow access to DHCPv6 server on LAN

                          pass quick on $LAN inet6 proto udp from fe80::/10 to fe80::/10 port = 546 ridentifier 1000002551 label "allow access to DHCPv6 server"

                          pass quick on $LAN inet6 proto udp from fe80::/10 to ff02::/16 port = 546 ridentifier 1000002552 label "allow access to DHCPv6 server"

                          pass quick on $LAN inet6 proto udp from fe80::/10 to ff02::/16 port = 547 ridentifier 1000002553 label "allow access to DHCPv6 server"

                          pass quick on $LAN inet6 proto udp from ff02::/16 to fe80::/10 port = 547 ridentifier 1000002554 label "allow access to DHCPv6 server"

                          pass in quick on $LAN inet6 proto udp from fe80::/10 to 2001:2042:334b:c300:a236:9fff:fe7a:603f port = 546 ridentifier 1000002555 label "allow access to DHCPv6 server"

                          pass out quick on $LAN inet6 proto udp from 2001:2042:334b:c300:a236:9fff:fe7a:603f port = 547 to fe80::/10 ridentifier 1000002556 label "allow access to DHCPv6 server"

                          But as IPv6 seems to use port 5355 for something called link-local resolution according to google (https://www.google.com/search?q=ipv6+5355)
                          those presets does not help.

                          So adding the rule adds the missing config (probably could be more restrictive to only match 5355):

                          pass in quick on $LAN inet6 from fe80::/10 to ff02::/16 ridentifier 1752488409 keep state label "USER_RULE" label "id:1752488409"

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