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

    Issues with Classless Static Route Option for DHCP (not fully supported RFC3442)

    Scheduled Pinned Locked Moved Routing and Multi WAN
    3 Posts 2 Posters 3.3k 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.
    • S
      Sebbo
      last edited by

      Hi,

      in cooperation with my cloud hoster we've experienced an issue with the "Classless Static Route Option" for DHCP.

      The "Classless Static Routing Option" is defined as RFC3442 and is used for configurations regarding the routes:
      @IETF/RFC3442:

      Classless Route Option Format

      The code for this option is 121, and its minimum length is 5 bytes.
        This option can contain one or more static routes, each of which
        consists of a destination descriptor and the IP address of the router
        that should be used to reach that destination.

      Code Len Destination 1    Router 1
        +–---+---+----+-----+----+----+----+----+----+
        | 121 | n | d1 | ... | dN | r1 | r2 | r3 | r4 |
        +-----+---+----+-----+----+----+----+----+----+

      Destination 2      Router 2
        +----+-----+----+----+----+----+----+
        | d1 | ... | dN | r1 | r2 | r3 | r4 |
        +----+-----+----+----+----+----+----+

      In the above example, two static routes are specified.

      […]

      DHCP Client Behavior

      DHCP clients that do not support this option MUST ignore it if it is
        received from a DHCP server.  DHCP clients that support this option
        MUST install the routes specified in the option, except as specified
        in the Local Subnet Routes section.  DHCP clients that support this
        option MUST NOT install the routes specified in the Static Routes
        option (option code 33) if both a Static Routes option and the
        Classless Static Routes option are provided.

      DHCP clients that support this option and that send a DHCP Parameter
        Request List option MUST request both this option and the Router
        option [4] in the DHCP Parameter Request List.

      DHCP clients that support this option and send a parameter request
        list MAY also request the Static Routes option, for compatibility
        with older servers that don't support Classless Static Routes.  The
        Classless Static Routes option code MUST appear in the parameter
        request list prior to both the Router option code and the Static
        Routes option code, if present.

      If the DHCP server returns both a Classless Static Routes option and
        a Router option, the DHCP client MUST ignore the Router option.

      Similarly, if the DHCP server returns both a Classless Static Routes
        option and a Static Routes option, the DHCP client MUST ignore the
        Static Routes option.

      After deriving a subnet number and subnet mask from each destination
        descriptor, the DHCP client MUST zero any bits in the subnet number
        where the corresponding bit in the mask is zero. In other words, the
        subnet number installed in the routing table is the logical AND of
        the subnet number and subnet mask given in the Classless Static
        Routes option. For example, if the server sends a route with a
        destination of 129.210.177.132 (hexadecimal 81D4B184) and a subnet
        mask of 255.255.255.128 (hexadecimal FFFFFF80), the client will
        install a route with a destination of 129.210.177.128 (hexadecimal
        81D4B180).

      Our issue was, that pfSense wasn't able to set the default route with the correct IP address and the result of it was, that pfSense wasn't able to reach any host, because any ping returned "No route to host". (The default route was just missing in the "netstat -rn" output.)

      Public WAN IP addresses are reserved to specific MAC addresses by their DHCP server. Each client will receive it's IP with a default /32 subnet mask, while the router is always the x.x.x.1.

      Example (with private IPs):
      Client IP: 192.168.2.123/32
      Router for this client: 192.168.2.1

      It's confusing, but it works, if I configure it with following commands manual:

      ifconfig vtnet0 192.168.2.123 255.255.255.255
      route add default 192.168.178.1
      

      I've added those lines in the /etc/rc.conf to load this configuration after a reboot.

      My cloud hoster checked this issue and said, that the package "isc-dhcp43-client" would solve all those issues.

      I also have a suggestion regarding the console configuration for IP addresses: Please add the option to set a /32 subnet mask for IP addresses. Regarding the above explained situation it also would be better to not validate, if the gateway IP address is within the provided subnet of the NICs IP address. Or you just don't validate the gateway, if the subnet mask of the IP address is /32.

      Hope, you can fix this issue as soon as possible. For further information, please don't hesitate to contact me.

      1 Reply Last reply Reply Quote 0
      • R
        rubic
        last edited by

        Hi, pfSense seems to work fine with option 121. As far as I can see, your scenario is so-called "foreign gateway" within the same shared medium. Thereby the hoster should provide not only gateway IP with DHCP option 121 but also "SameSM" route to the gateway.

        For example, assuming gateway IP is 203.0.113.1, 121-option data looks like this: 20:cb:00:71:01:00:00:00:00:00:cb:00:71:01

        Here:

        20:cb:00:71:01:00:00:00:00 means 203.0.113.1/32 via 0.0.0.0 - "SameSM" or "On-Link" route to the gateway
        00:cb:00:71:01 means 0.0.0.0 via 203.0.113.1 - default route

        As a result, RT of the pfSense box recieved the data is:

        Can you share full detail packet capture of the DHCP ACK the hoster sends to you?

        PS sorry for bad english

        1 Reply Last reply Reply Quote 0
        • S
          Sebbo
          last edited by

          Thanks for your answer!

          I've forwarded your answer to the network team of my provider and they told me, that this isn't supported.

          Well… Ok, it's no issue of pfSense. Great! :)

          #Closed

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