• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 892
  • Last Modified:

TFTP Oddity - Works, but doesn't


This is strange. I have 2 subnet connected via a VPN tunnel between two Netopia R910 routers. The DHCP/TFTP server is on a Windows 2003 SBS on Network A. There is a PC on Network B that recieves its IP from the DHCP server on Network A (via DHCP relay on the R910 router). I can run tftp from the command line of the PC on Network B to the TFTP server on Network A and retrieve files all day long.

c:>tftp -i get pxelinux.0 <--this works fine

However, if I try to boot a PC on network B using PXE, the pxelinux.0 file fails to get read. The TFTP log shows that the DHCP server tells the booting client to read the file, but then the read fails. I don't understand this. Is this a routing issue of some kind? The VPN tunnel does not NAT any traffic.

Any ideas appreciated.

Aaron J. Wood
  • 2
  • 2
1 Solution
The issue is that your PXE booted system uses A's network IP while your test system uses B's network information.

You need to configure the DHCP on Network B to assign a local Network B IP/gateway, but set the tftp option to the Network A

i.e. Network A has the
Network B has
When the PXE broadcasts a BOOTP/DHCP packet, the current setup relays the requests to Network A and then relays back to the client a gateway
Network B router can not route this IP segment traffic as it is foreign to it.  Additionally, access attempts by this client to a 10.0.1.x IP is attempted directly and will never be sent to (router)

I believe normally if you have a boot server on a different segment, you have to use a local DHCP server to get the system on the network by assigning local segment IPs/gateway.  You can use a DHCP relay, provided you have define the right scopes on the remote DHCP server to assign a network B IP when a request is coming from there.
aaronjwoodAuthor Commented:
Hmmm...let me explain my setup in more detail.

Network B ( does not have a DHCP server. It consists of a Cable modem --> Netopia R910 Router ( --> 2 PCs connected to router. The R910 has a VPN tunnel established to Network A's R910 router and relays DHCP requests from B to A. The VPN tunnel does not NAT or filter any traffic. Network A ( has the DHCP/TFTP server ( It consists of a ADSL modem (bridged) --> Netopia R910 Router ( --> switch --> lots of PCs and DHCP/TFTP server connected to switch. The DHCP server is set up with a superscope that serves IP addresses to different subnets. For example...the PCs on network B DO IN FACT GET an IP within the - range. The DHCP server also defines the DHCP options 66 and 67 for boot server host ( and boot file name (pxelinux.0). Therefor the traffic should not be foreign to Router B.

This issue continues to stump me. Are there other settings that need to be set in the DHCP options for the scope?  Is there any way to see where the packet is failing? Any other ideas?

The only thing I can think of is that the BOOTP (options 66/67 are not making it through the relay).  I think it is a two step process.  Broadcast a request for IP on DHCP.  Once there is an IP broadcast an ARP request for the BOOTP options.  The PXE client gets the IP, but the ARP requests do not make it accross the VPN.  Does your DHCP relay also relays BOOTP ARP requests to the server on Network A??
aaronjwoodAuthor Commented:
SOLVED: I have been working on this for two weeks straight and just now solved the problem. The answer was the block size setting of the tftp server. I had to lower it to 1024 and then the boot files transfered without any problem via pxe boot. This is odd because there was no documentation I could find on this. I actually just got lucky and unchecked the allow block size option on the tftp server and it worked. I then slowly raised the block size until I reached the max it could handle. I guess that the default block size is too large to traverse a IPSec VPN tunnel. Maybe one of the experts could shed some light on this. I am just thankful to get it solved. I will leave this open for now to see if I get any explainations on the solution.

Thanks for the help.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now