Change TTL-value of DHCP Requests

[an10bill]

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??

[johnpoz]

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?

[NOYB]

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

[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
1  c-24-13-176-1.hsd1.il.comcast.net (24.13.xxx.1)  27.012 ms  29.116 ms  58.128 ms
2  te-1-2-ur08.mtprospect.il.chicago.comcast.net (68.85.131.153)  21.883 ms  16.685 ms  14.250 ms
3  te-8-4-ur07.mtprospect.il.chicago.comcast.net (68.86.187.201)  24.502 ms  9.570 ms  9.793 ms
4  te-1-9-0-3-ar01.elmhurst.il.chicago.comcast.net (68.86.187.213)  11.792 ms  15.435 ms  15.490 ms
5  te-9-2-ur04.area4.il.chicago.comcast.net (68.87.230.214)  14.356 ms  13.157 ms  13.642 ms
6  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??

[NOYB]

@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.

[an10bill]

@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
1  c-24-13-176-1.hsd1.il.comcast.net (24.13.xxx.1)  27.012 ms  29.116 ms  58.128 ms
2  te-1-2-ur08.mtprospect.il.chicago.comcast.net (68.85.131.153)  21.883 ms  16.685 ms  14.250 ms
3  te-8-4-ur07.mtprospect.il.chicago.comcast.net (68.86.187.201)  24.502 ms  9.570 ms  9.793 ms
4  te-1-9-0-3-ar01.elmhurst.il.chicago.comcast.net (68.86.187.213)  11.792 ms  15.435 ms  15.490 ms
5  te-9-2-ur04.area4.il.chicago.comcast.net (68.87.230.214)  14.356 ms  13.157 ms  13.642 ms
6  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.

[an10bill]

@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?

[johnpoz]

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.

[NOYB]

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

[johnpoz]

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 ;)

[NOYB]

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.

[an10bill]

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....

[NOYB]

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.

[johnpoz]

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 ;)

[an10bill]

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 :-)

[dhatz]

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 …

[johnpoz]

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?

[an10bill]

@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?

[johnpoz]

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.

[an10bill]

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!!!!