[SOLVED]
Sorry for the second post...I posted under the wrong subject last time.
It turns out that the whole issue was the block size of the tftp transfer.
For some reason when transferring from a booted pc or a pxe LAN boot this is
not an issue. However, when transferring during a VPN pxe boot it is. I have
no idea why, but I had to use the -B option in my tftp line in inetd.conf
and assign a block size of 1024. Once I restarted inetd the pxe VPN worked.
Unfortunately it take over an hour to transfer the files and mount the file
system. So...although the transfer problem has been fixed I am back to the
drawing board with my LTSP deployment method.
Any explanation on the block size reasoning would be great to hear.
Regards,
Aaron J. Wood
Sun Tire Services, Inc.
On Thu, Jun 12, 2008 at 7:13 AM, Aaron J. Wood <[EMAIL PROTECTED]> wrote:
> David,
>
> Thank you very much for the input. I would tend to agree with you however I
> have been very careful to eliminate the VPN/Firewall. The VPN tunnel between
> the two routers is an IPsec tunnel and does not filter or NAT any of the
> traffic. Also, there is no firewall on the TFTP server. Even stranger is why
> does tftp work from the command line. I can do a "tftp -i 10.0.1.10 get
> pxelinux.0" the file is transferred without any problem. It is only when the
> tftp is initiated by pxe boot that is fails. The only difference in the tftp
> log files between these two transfers is that one shows the request coming
> from a specified host, the other just shows a request to read the file (no
> host specified).
>
> I am still baffled by this issue. Any other ideas?
>
> Regards,
> Aaron J. Wood
> Sun Tire Services, Inc.
> --
> Sent via BlackBerry from T-Mobile
>
>
> -----Original Message-----
> From: "David Burgess" <[EMAIL PROTECTED]>
>
> Date: Wed, 11 Jun 2008 17:50:42
> To:ltsp-discuss@lists.sourceforge.net<[EMAIL PROTECTED]>
> Subject: Re: [Ltsp-discuss] PXE Boot over multiple Subnets using W2003
> SBSasDHCP Server
>
>
> Your ISP has no idea what is crossing your VPN, so as you have indicated
> that other things function across the VPN, you can rule out your ISP.
>
> My hunch is that this is indeed a VPN/firewall issue. It appears you're
> running IPSEC tunnels from the same machines that are doing the firewalling
> and routing. Check your firewall rules. Some VPN firewalls will filter your
> VPN packets based on content and others will not. Yours is likely the former
> or you wouldn't be having the problem. Try allowing everything through the
> VPN tunnel in both directions. If that works then you may have to re-enable
> rules on the tunnel selectively to see where the problem is.
>
> Alternatively, some NAT routers will reroute the source port of your
> outgoing packets and others do not (or they do by default and they can be
> programmed not to). The former behaviour will cause problems with some
> programs. I'm not familiar with how ltsp works on the network, but this
> could be your issue.
>
> In both of the above cases though, wireshark or tcpdump should show packets
> exiting the tftp server and failing only at the firewall or VPN router.
>
> db
>
>
> On Wed, Jun 11, 2008 at 4:01 PM, Aaron J. Wood <[EMAIL PROTECTED]<mailto:
> [EMAIL PROTECTED]> > wrote:
> Update:
>
> I am now 90% sure that this is a routing or VPN issue. Here is why. I was
> able to duplicate the remote subnet at work minus the VPN tunnel. I
> connected the same router to the network and assigned a private IP of
> 10.0.1.8 <http://10.0.1.8> to the WAN side. I then assigned the LAN side
> of the router 192.168.50.1 <http://192.168.50.1> and enabled DHCP relay
> on the router to direct DHCP requests to the DHCP server on the 10.0.1.X
> network. The DHCP server has the setting to direct clients to the boot
> host,file etc. At first the same thing happened. The process stalled after
> sending the read request for pxelinux.0. Then I added a static rout to the
> LTSP/TFTP server pointing 192.168.50.0 <http://192.168.50.0> traffic to
> 10.0.1.8 <http://10.0.1.8> . Well, it worked! The thin client was able to
> boot from the other subnet. However, with the subnet separated by a VPN
> tunnel I cannot get the pxelinux.0 file to transfer. I have tried the add a
> static route point traffic for the remote subnet to the router IP and many
> other things, but still a no go. Maybe the ISP is b
> locking something or this just won't work over a VPN.
>
> Any other ideas? Anyone?
>
> Regards,
> Aaron J. Wood
> Sun Tire Services, Inc.
> --
> Sent via BlackBerry from T-Mobile
>
>
>
> -----Original Message-----
> From: Steve Cayford <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >
>
> Date: Sun, 08 Jun 2008 17:45:17
> To:ltsp-discuss@lists.sourceforge.net<[EMAIL PROTECTED]><mailto:
> [EMAIL PROTECTED]<[EMAIL PROTECTED]>
> >
> Subject: Re: [Ltsp-discuss] PXE Boot over multiple Subnets using W2003 SBS
> asDHCP Server
>
>
>
>
>
> Okay, that shot down all my theories. I don't know where else to look at
> the moment.
>
> -Steve
>
>
> Aaron J. Wood wrote:
> > Steve,
> >
> > I am writing this fast as I am running out the door. I booted a windows
> > machine on the remote subnet and was able to retrieve the pxelinux.0
> file
> > from the windows machine via tftp. I ran the following command and
> received:
> >
> > c:>tftp 10.0.1.4 <http://10.0.1.4> get /ltsp/i386/linuxpxe.0
> > Transfer Successful: 13628 bytes in 4 seconds
> >
> > So this means that tftp is working and not being blocked. This has got
> to be
> > something else. I will read your email in detail when I return home and
> post
> > any update.
> >
> > Regards,
> > Aaron J. Wood
> > Sun Tire Services, Inc
> > 904-693-0990
> >
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php <
> http://sourceforge.net/services/buy/index.php>
> _____________________________________________________________________
> Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
> https://lists.sourceforge.net/lists/listinfo/ltsp-discuss <
> https://lists.sourceforge.net/lists/listinfo/ltsp-discuss>
> For additional LTSP help, try #ltsp channel on irc.freenode.net <
> http://irc.freenode.net>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php <
> http://sourceforge.net/services/buy/index.php>
> _____________________________________________________________________
> Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
> https://lists.sourceforge.net/lists/listinfo/ltsp-discuss <
> https://lists.sourceforge.net/lists/listinfo/ltsp-discuss>
> For additional LTSP help, try #ltsp channel on irc.freenode.net <
> http://irc.freenode.net>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _____________________________________________________________________
> Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
> https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
> For additional LTSP help, try #ltsp channel on irc.freenode.net
>
>
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freenode.net
