Change TTL-value of DHCP Requests



  • I've noticed that the WAN interface (em0) sends out DHCP-requests with a TTL-value of 16 (Wireshark). When connecting to an ISP bridged modem, it is my understanding that DHCP requests are sent all the way to the ISP's DHCP-server, located somewhere on their internal network. Depending on how their network is built, it might be more than 16 hops to this server, and in that scenario there will never be a response, since the requests never hit the server. You'll get no DHCP connection.

    My D-link router has no issues getting an DHCP-request from my ISP, while my pfSense-box has….. Connecting the pfSense behind the D-link, results in an a DHCP response without problems. The only reason I can think of is TTL-value and the possability that there might be more than 16 hops to the DHCP, as D-link sends it's requests with a TTL-value of 128, while pfSense has TTL-value of 16.....and the latter never gets through.
    (Fyi,  I've tried shutting down the bridged modem for 10 minutes, before trying DHCP. I've tried to clone the D-link's MAC (all the easy tryouts and suggestions from reading several forumposts) etc etc.... Results are the same everytime. D-link or a PC with Windows gets a DHCP response without any problems (don't even need to shutdown the bridged modem, nor clone any mac's) , while pfSense tries and tries no matter what I do, but never gets response) - I believe this might be caused by the low TTL-value of the requests.....

    Is there any way of changing the default TTL-value of DHCP-requests from the WAN interface??


  • LAYER 8 Global Moderator

    Hmmm,  I believe those can be set with dhclient options

    option default-ip-ttl uint8;
    This option specifies the default time-to-live that the client should use on outgoing datagrams.
    option default-tcp-ttl uint8;
    This option specifies the default TTL that the client should use when sending TCP segments. The minimum value is 1.

    But not sure of the details of how pfsense uses dhclient, or if these are valid options for freebsd?

    http://www.unix.com/man-page/FreeBSD/5/dhcp-options/
    So looks like freebsd has these options as well

    option default-ip-ttl uint8;
        This option specifies the default time-to-live that the client should use on outgoing datagrams.
    option default-tcp-ttl uint8;
        This option specifies the default TTL that the client should use when sending TCP segments.  The minimum value is 1.

    I am curious why it would be set to 16 in the first place?  Why not 8, or 32 - who came up with 16?  Kind of hard to sniff a dhcp discover on my pfsense wan while I am remoted in via openvpn without killing my session I think.  But I will validate that ttl your seeing for sure when I get home.  If its not using the default ttl of the OS which from sysctl looks to be 64,

    [2.1-BETA0][admin@pfsense.local.lan]/root(1): sysctl net.inet.ip.ttl
    net.inet.ip.ttl: 64

    Then I would have to assume it can be adjusted somewhere.

    edit:  Ok I found where the default is set and yup verifies the 16 your seeing
    http://svnweb.freebsd.org/base/release/8.3.0/sbin/dhclient/packet.c?revision=234063&view=markup

    ip.ip_ttl = 16;

    So I if you can not use the option in /var/etc/dhclient_wan.conf you may have to recompile the dhclient to get it changed?



  • Do a trace route to the DHCP server to see how many hops it is.


  • LAYER 8 Global Moderator

    that may help verify that his ttl is the problem, but sometimes that the IP of dhcp server could be a private one.  So from my comcast connection took a look to see what IP of my dhcp server was, doing a trace shows 6 hops

    traceroute to 69.252.202.7 (69.252.202.7), 64 hops max, 40 byte packets
    c-24-13-176-1.hsd1.il.comcast.net (24.13.xxx.1)  27.012 ms  29.116 ms  58.128 ms
    te-1-2-ur08.mtprospect.il.chicago.comcast.net (68.85.131.153)  21.883 ms  16.685 ms  14.250 ms
    te-8-4-ur07.mtprospect.il.chicago.comcast.net (68.86.187.201)  24.502 ms  9.570 ms  9.793 ms
    te-1-9-0-3-ar01.elmhurst.il.chicago.comcast.net (68.86.187.213)  11.792 ms  15.435 ms  15.490 ms
    te-9-2-ur04.area4.il.chicago.comcast.net (68.87.230.214)  14.356 ms  13.157 ms  13.642 ms
    chic4-pdhcp.area4.il.chicago.comcast.net (69.252.202.7)  11.306 ms  12.794 ms  12.479 ms

    I don't see where in gui in pfsense you can see that info, I had to look in /var/db/dhclient.leases.em1

    Pretty sure since he says he can get an IP via is workstation, he could look there to see the IP of his dhcp server.  This is a good way to see if TTL could be the problem.  Seems crazy that you could be like 16+ hops away from your dhcp server doesn't it??



  • @johnpoz:

    Pretty sure since he says he can get an IP via is workstation, he could look there to see the IP of his dhcp server.  This is a good way to see if TTL could be the problem.

    That's what I was thinking anyway.

    @johnpoz:

    Seems crazy that you could be like 16+ hops away from your dhcp server doesn't it??

    Seems it would be the very rare exception.  Is there anything in the DHCP spec that requires it be 16 or less hops?  If so, maybe that's why the TTL is 16.



  • @johnpoz:

    that may help verify that his ttl is the problem, but sometimes that the IP of dhcp server could be a private one.  So from my comcast connection took a look to see what IP of my dhcp server was, doing a trace shows 6 hops

    traceroute to 69.252.202.7 (69.252.202.7), 64 hops max, 40 byte packets
    c-24-13-176-1.hsd1.il.comcast.net (24.13.xxx.1)  27.012 ms  29.116 ms  58.128 ms
    te-1-2-ur08.mtprospect.il.chicago.comcast.net (68.85.131.153)  21.883 ms  16.685 ms  14.250 ms
    te-8-4-ur07.mtprospect.il.chicago.comcast.net (68.86.187.201)  24.502 ms  9.570 ms  9.793 ms
    te-1-9-0-3-ar01.elmhurst.il.chicago.comcast.net (68.86.187.213)  11.792 ms  15.435 ms  15.490 ms
    te-9-2-ur04.area4.il.chicago.comcast.net (68.87.230.214)  14.356 ms  13.157 ms  13.642 ms
    chic4-pdhcp.area4.il.chicago.comcast.net (69.252.202.7)  11.306 ms  12.794 ms  12.479 ms

    I don't see where in gui in pfsense you can see that info, I had to look in /var/db/dhclient.leases.em1

    Pretty sure since he says he can get an IP via is workstation, he could look there to see the IP of his dhcp server.  This is a good way to see if TTL could be the problem.  Seems crazy that you could be like 16+ hops away from your dhcp server doesn't it??

    Good Idea, I'll do a trace to check the hops to the server. I know it's seeming a bit odd that there would be that many hops, but this is a Norwegian Fiber ISP (Altibox), and they're owned and controlled by a fiber company (LYSE) which main office is located in the far west of  southern Norway, and Altibox have a bunch of local power-distributors that are acting as local Fiber ISP's for different parts of Norway. Me is located almost on the far eastern part of Norway and buy my services from one of these local ISP's, and the way I have understood their infrastructure, it seems most is controlled from the main office in far west of southern Norway. I don't think they have local DHCP's for all these regions, and it seems that everything about customers, and their connections, modems etc are controlled from main office, so I think that's where the DHCP is located. But how the traffic-pattern for their internal network is laid out, I don't know…. There is almost 600km between my house and their main office... and there is no way that there is a direct line..... But how many hops? A "trace" might reveal, if i manage to find the address of the DHCP and trace it.



  • @johnpoz:

    Hmmm,  I believe those can be set with dhclient options

    edit:  Ok I found where the default is set and yup verifies the 16 your seeing
    http://svnweb.freebsd.org/base/release/8.3.0/sbin/dhclient/packet.c?revision=234063&view=markup

    ip.ip_ttl = 16;

    So I if you can not use the option in /var/etc/dhclient_wan.conf you may have to recompile the dhclient to get it changed?

    Nice - I'll look into it, trying to change the options in /var/etc/dhclient_wan.conf and confirm with Wireshark that packets actually get the new value and then to see if a higher TTL will actually give me a response from the DHCP Server, or if this whole TTL thing turns out to be me barking up the wrong tree…. Atleast I'll get one more "checkmark" on my list of tryouts to solve this, and I can then move along and find a new tree to bark at  :P - but I'm pretty close to run out of Idea's now..... But hey, It also might actually work  ;) Guess I'll find out once I'm home from work.....

    PS: If the options are ignored and packets still get the default value of 16, how do I get by actually trying to recompile the dhclient? I'm decently skilled in virtualization, networking and general computer knowhow, but nix based systems and their lookalikes have never been my strong side…. I've played around with them from time to time, but a little cooking-recipe from someone who have some more experience would sure be welcome :-)

    Edit: Actually did try this now at work, with a pfSense installed on a VMware Workstation…... changed the dhcp_wan.conf file, adding the option default-ip-ttl 64 and default-tcp-tll 64 and saving the file. Then I reset the server and did some testing. Packets are still according to tcp-dump sent out with a TTL value of 16. Going back to the dhcp_wan.conf to look for spelling errors, I discover that the mod's are not there. The file is back to original. How to I make these edits stick and survive a reboot without being overwritten?? No wonder why the TTL value was still 16 when the options were lost in the reboot.
    PS: If there is no way to make this edits stick during reboot, how can I atleast make them applied in current "session" so that a new release/renew of the em0 interface will use these settings?


  • LAYER 8 Global Moderator

    looks like we have a problem.

    To get that to change, you can edit etc/inc/interfaces.inc

    So I have released and renewed my em1 (wan) multiple times, check the dhclient_wan.conf and shows my option in there

    interface "em1" {
    timeout 60;
    retry 15;
    select-timeout 0;
    default-ip-ttl 33;
    initial-interval 1;

    script "/sbin/dhclient-script";
    }

    Tried it with option in the front as well

    interface "em1" {
    timeout 60;
    retry 15;
    select-timeout 0;
    option default-ip-ttl 33;
    initial-interval 1;

    script "/sbin/dhclient-script";
    }

    Problem is, still sending out ttl 16
    07:39:15.276503 00:50:56:00:00:01 (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto UDP (17), length 328)

    So google found this, this is pretty much your problem with too low of ttl - seems its not reading the options to set that?

    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=161690

    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=152287

    Sure someone here can help you recompile dhclient?  Have you had a chance to do a traceroute to see how many hops?

    edit:  Ok I tried to get this to work on my ubuntu box, to see if I could get the dhclient to change the ttl, and no go - it sends TTL of 128, but making changes to the dhclient.conf did not seem to have any effect on option default-ip-ttl, tried it with option, not option in front, etc.  Didn't seem to do anything - still always 128

    still seems to be a bug with this reading that option?  I even tried placing it outside the interface section

    option default-ip-ttl 33;
    default-ip-ttl 33;

    interface "em1" {
    timeout 60;
    retry 15;
    select-timeout 0;
    initial-interval 1;

    script "/sbin/dhclient-script";
    }

    Just does not seem to read that option, would have to go through source to find out why.  Look like you need a recompile or submit bug to freebsd about dhclient not accepting that option.  Seems to be in ubuntu as well though.  Pretty sure I could get that compiled and checked out..  I just don't have any development setup for freebsd.



  • Rather than editing /etc/inc/interfaces.inc to change the value, this patch for dhclient additional options and override dhclient config file may be useful:

    http://forum.pfsense.org/index.php/topic,40194.0.html


  • LAYER 8 Global Moderator

    that looks like a cool patch, but don't see where you can modify default-ip-ttl?

    And to be honest I have tried putting them in, and does not seem like the dhclient makes use of them.  Which is the big issue, does not matter how you get them to the dhclient - if he is not going to pay attention to them ;)



  • Use the Config File Override option.

    Yes, whether or not dhclient will make use of that option specified in a config file is another matter.  This patch just makes customization easier.

    Though the OP'er still hasn't confirmed the dhcp server hop count.  So it may not even be relevant.



  • I've tried to trace down the DHCP, but the tracert gives no responses, and It just traces until reaching max defined hops…... Tried with a max of 30 hops, and it went all the way to 30 hops and stopped there. - Guess the ISP have some firewalls blocking the icmp responses all the way.....

    So I've sent them an email requesting some info - I'll post back as soon as I get an response from them.

    In the meantime I've also tried to circumvent the DHCP issue by using the D-link to initiate the DHCP, and then hotswap the cable with the pfsense (configured with the exact same IP-settings, only static, and ofcourse with the d-link's mac spoofed.... so that em0 uses the d-link's mac.....Hoping I could use this as a workarond solution, But thats also a "no go" - I was hoping the firewall of the ISP would enable traffic once DHCP was established, and then never be the wiser about pfsense suddenly beeing the source..... but I was wrong.... It surely senses the connection drop, even if it's only seconds, and breaks the established connections....Atleast I never get any traffic through (reswapping the cable to the d-link, and link is straight back after a renegotiate of dhcp)

    So still running my pfsense behind the d-link here, waiting for some feedback from the ISP (but I'm not optimistic - since my setup is so far off in regards to what they support, I believe the will only blow me off with some bullshit....) - but crossing fingers hoping I get a decent support-representative on my case....



  • There are ways for the determined.

    I've gone so far as to do this before.  A bit tricky and delicate, but it works.

    http://www.dslreports.com/forum/r27210694-FiOS-Dual-Router-Separated-Computer-TV-Service-Networks

    Except in your case since pfSense is unable to get a DHCP lease it would have to be static of the ISP's router DHCP address.

    Who knows.  It might work.  Never know what can be accomplished unless you try.

    Best of luck to you with the ISP.


  • LAYER 8 Global Moderator

    Ok here you go - I changed the packet.c source of dhclient to reflect a new ttl 128 vs the 16

    I tried getting the development version of pfsense working, but the ova they have wasn't working just kept running some background script every 30 and failing.  So I just grabbed real copy of freebsd 8.3, installed developers version on a vm.  Then simple edit of the packet.c

    ip.ip_ttl = 128;

    then a simple make, and there you go - now it uses ttl of 128, see attached screenshot.  I tested it on my pfsense as you can see by the screenshot so should run on your pfsense no issues.. You are using 32 bit right?

    Just rename your /sbin/dhclient to dhclient.old or something and replace with the new version and if your problem is really just too low of TTL you should be good to go.

    
    [2.1-BETA0][root@pfsense.local.lan]/sbin(2): ls -la dh*
    -r-xr-xr-x  1 root  wheel  90150 Jul 28 03:16 dhclient
    -rwxr-xr-x  1 root  wheel   9938 May 12 07:25 dhclient-script
    -r-xr-xr-x  1 root  wheel  78828 Mar 21 07:54 dhclient.old
    
    

    guess you can not add .zip files  Here is link off my dropbox
    https://www.dropbox.com/s/igj7z92e6eogyme/dhclient.zip

    if this works - then yeah we need to get this supmitted as actual bug and updated or fixed correct by freebsd, and then pfsense can update to the new version of dhclient.  If I get a chance this weekend maybe I will take a look to why its not reading the options that are suppose to be there, now that I have a freebsd vm I can build on.

    Please let me know if this works for you - hope it does!  Not really sure why its so much bigger?  All I did was edit that one line from 16 to 128..  Just so you know, I am not by any means a developer or programmer.  I just dabble and just enough know how to find stuff like this that can be edited and any idiot can run make ;)




  • Thanks a lot for your effort with recompiling the dhclient, but sadly I was stupid enough to install the 64-bit edition of pfsense, so it will probably not work for me…... - But since it's easy enough to install on ESXi, I can keep my currently installed server, just shut it down, and then just try out a 32-bit with your recompiled DHclient..... If it works, well, then I can always run on the 32bit from there.... or go for a recompiled dhclient for 64bit, but 64 bit is actually not necessary, so if it works with your 32-bit fie, i'll probably run with 32-bit from there :-)

    Thanks a lot - I'll go right ahead and intall the 32-bit and try out your new dhclient. I'll post my results once tested :-)



  • Is there any requirement (RFC etc) for dhclient using a ttl of 16 ? Because I couldn't find any.

    On the other hand, it hard to imagine why this issue hasn't been fixed yet, since it has been 10 years since those Debian bug reports …


  • LAYER 8 Global Moderator

    I would have to fire up debian to verify, or look at their code - but I have to assume it was fixed in their version of the dhclient.

    But as you can see from this thread the one in freebsd only uses 16 as the ttl, I don't understand why doesn't just use the default os setting?

    Then again its got to be rare as hell that your dhcp server would be more than 16 hops??  We are not even sure that is the OP problem.  We should find out soon enough once he runs with my recompiled dhclient that has 128 ttl vs the 16.

    I sure hope it fixes his problem, then we can work on getting the code fixed and maybe someone can explain why you would set it to 16?  I can understand thinking - well why and the hell would a broadcast ever go over 16 hops ;)  But then again why set a limit in the client in the first place?  Why not just use the OS default?



  • @johnpoz:

    Just rename your /sbin/dhclient to dhclient.old or something and replace with the new version and if your problem is really just too low of TTL you should be good to go.

    
    [2.1-BETA0][root@pfsense.local.lan]/sbin(2): ls -la dh*
    -r-xr-xr-x  1 root  wheel  90150 Jul 28 03:16 dhclient
    -rwxr-xr-x  1 root  wheel   9938 May 12 07:25 dhclient-script
    -r-xr-xr-x  1 root  wheel  78828 Mar 21 07:54 dhclient.old
    
    

    Fileupload broken?? I can't seem to upload files to the 32 bit pfsense. Using the built in gui (under diagnostic) to upload, nothing happens when upload is pressed, and the file never get transferred. I then installed the FileManager package, but whenever trying to upload i get the error "File Upload stopped by extension!"…. Tried ff and inet explorer.... both have same error....

    Any ideas?


  • LAYER 8 Global Moderator

    just sftp to the box - that is how i move files on and off my pfsense.

    edit:  And you want to make sure you client sends binary and not ascii.



  • johnpoz, You're THA' MAN! :-)

    Seems your recompiled DHCLIENT actually solved my issue. This message is sent from my PC through pfsense, now for the first time with an offical IP straight from my ISP on the wan interface. Bye bye D-link inbetween.

    If it actually was the number of hops beeing more than 16, or my ISP having a security setting whacking off DHCP-requests with less normal TTL's (most OS'es and standalone router boxes uses 64 or 128 TTL), I don't know -  but with DHclient now sending out requests with TTL 128, I now have a DHCP lease on my em0 interface via bridged ISP-modem through my VLAN on core switch and via ESXi vswitch down to my pfsense…. Damn It feels good finally getting this piece of puzzle fitted :-)

    I should probably get off to bed, because I'm off to work in 5 hours - but right now I feel I have to celebrate first with one beer!..... Cheers! and thank's for the help all of you!!!!


  • LAYER 8 Global Moderator

    Glad it fixed your issue, it was fun for me to get a freebsd up and running I can compile stuff on in the future ;)

    You know the security issue –- hmm I wonder??  Guess we could up the ttl and see what is the min to work, if its like 64 then most like a security thing.

    I would love to know how many hops its away ;)  It just blows my mind that you could be 16 hops away, that just nuts!!  And seems like piss poor network design to me as well.  But without a understanding of their network - maybe its 17 hops and that is the best way to setup what they want?  But seems unlikely..

    Just finally glad we got you working..  Now should report this to freebsd and actually get it fixed, I wonder others out there just don't get an IP and give up??  I was pretty impressed that you noticed the ttl being low, I am curious if I would of spotted that if I was having a sim issue.  I now for sure will if I ever see such a problem in the future!



  • I don't know if it's a security issue or not - because my ISP hasen't responded to my support-ticket yet (if they ever will), but I'm also thinking it would be a pretty piss-poor network design if the DHCP could actually be more than 16 hops away…. But then again I have been working with computers and network for so long time, that nothing actually surprises me anymore. Since your modified dhclient solved the problem, it seems likely that the TTL have been the issue (unless the ISP quietly have been doing some stuff regarding my support-ticket - but i don't think so) and the most likely scenario would then be some sort of firewall blocking odd-requests (and since the majority of systems send out requests with 64/128 TTL, anything else is considered abnormal and killed)....

    If I ever find the answer, if they respond, and I can say for sure that it was the hops or a security issue - I'll update this tread so that we can find pice of mind on this issue :-P

    In regard of reporting this, since a vast majority of people are just plugging their pfsense behind ISP routers (unbridged) or have ISP with less rigid/picky security systems, nor running advanced setups including both VLAN's and virtualization, then the TTL of 16 have been sufficient through earlier releases and no need for change have been noticed nor reported. But, as you say, for all of those who have been trying to get a DHCP through a bridged modem, directly from their ISP and NOT succeded, and then gave up after trying "everything" - this actually might be the overlooked solution.

    I can see no requiered reason for the dhclient to use TTL 16 when the default for all other traffic is either 64 or 128 - so this for sure is one thing that could/should make it into a new release of pfsense - or they could atleast make it something you can change easily with an optionsetting in the gui, or a config file :-)

    Me for sure is happy that I can now focus 100% on config and further setup, instead of wiresharking and troubleshooting network/vlan traffic. It have been fun in some odd way, and I've probably once again learned something.... at least that even the smallest and most unlikely things, might be the big difference ;-)


  • LAYER 8 Global Moderator

    Yeah I can see no reason for the 16 either, other OSes are not using such a low ttl for dhcp.  I would be curious what netbsd or openbsd are using.

    Maybe one of the developers for pfsense can help us with the official way of submitting the bug/issue and fixed in freebsd.  What I can tell you is I updated my pfsense yesterday and its back to the original dhclient - so if you update your going to have to replace your dhclient again.

    If for some reason they want to leave the default at 16, then it should be fixed so that the options of changing it works.



  • @johnpoz:

    What I can tell you is I updated my pfsense yesterday and its back to the original dhclient - so if you update your going to have to replace your dhclient again.

    Np, one thing I've definitely have learned over the years is the value of backup. Your modified dhclient, is ofcourse backed up, and duplicated both on my NAS, and somewhere in the cloud (Livedrive), just in case I have to do a reinstall/update of pfsense some time in the future…. ;-)

    Now, I'm off to battle the next phase in my setup - getting OpenVPN to work with ActiveDirectory and DuoSecurity Radius Proxy (2 factor auth). Hopefully that wil go smoother than getting DHCP to work ;-)


  • LAYER 8 Global Moderator

    I have submitted this as bug to freebsd, just waiting on confirmation that it was taken, will post link to report as soon as I get it here in this thread.

    Ok the problem has been posted - you can follow it here
    http://www.freebsd.org/cgi/query-pr.cgi?pr=170279


Log in to reply