Solved

TFTP Oddity - Works, but doesn't

Posted on 2008-06-11
4
838 Views
Last Modified: 2013-12-02
Hello,

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

Regards,
Aaron J. Wood
0
Comment
Question by:aaronjwood
  • 2
  • 2
4 Comments
 
LVL 76

Expert Comment

by:arnold
ID: 21766228
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 10.0.1.10.

i.e. Network A has the  10.0.1.0/24
Network B has 192.168.0.0/24.
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 10.0.1.145/24 gateway 10.0.1.1.
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 10.0.1.1 (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.
 
0
 

Author Comment

by:aaronjwood
ID: 21767997
Hmmm...let me explain my setup in more detail.

Network B (192.168.100.0/24) does not have a DHCP server. It consists of a Cable modem --> Netopia R910 Router (192.168.100.1) --> 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 (10.0.1.0/24) has the DHCP/TFTP server (10.0.1.10). It consists of a ADSL modem (bridged) --> Netopia R910 Router (10.0.1.254) --> 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 192.168.100.100 - 192.168.100.199 range. The DHCP server also defines the DHCP options 66 and 67 for boot server host (10.0.1.10) 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 192.168.100.0/24 scope?  Is there any way to see where the packet is failing? Any other ideas?

Thanks
0
 
LVL 76

Expert Comment

by:arnold
ID: 21768618
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??
0
 

Accepted Solution

by:
aaronjwood earned 0 total points
ID: 21772047
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.
0

Featured Post

Do You Know the 4 Main Threat Actor Types?

Do you know the main threat actor types? Most attackers fall into one of four categories, each with their own favored tactics, techniques, and procedures.

Join & Write a Comment

Suggested Solutions

Title # Comments Views Activity
Iptables and mirroring ports 4 46
RDP through VPN setup 9 42
WAN IP Conflict on Sonicwall 5 61
MDT 2013 Sysprep and Capture 1 15
There are two basic ways to configure a static route for Cisco IOS devices. I've written this article to highlight a case study comparing the configuration of a static route using the next-hop IP and the configuration of a static route using an outg…
Let’s list some of the technologies that enable smooth teleworking. 
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…

747 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now