I'm far from expert on these things, but here's what I think I'm seeing when
looking at your tcpdump output:
client makes request for pxelinux.0 to 10.0.1.4 on tftp port 69
10.0.1.4 responds from port 32800
Already this appears odd. Shouldn't 10.0.1.4 respond from port 69? Perhaps
you could boot a client on the local network and run tcpdump there. I
suspect you would only see packets from 10.0.1.4.69 >
We then see the client connecting to 10.0.1.4 on port 32800, but no
subsequent response from the server. The client then requests pxelinux.0
from the server on port 69, but this request originates from the client's
port 2071, rather than 2070 as before, indicating that it has given up on
the first request and is trying to start over.
I suspect that one of two things is happening:
1. The server is responding from port 69 but the vpn device on the server's
end is rewriting its packets so they appear to come from port 32800. I don't
think this is the case, because those packets are in response to an incoming
connection attempt from the client. This would be akin to trying to connect
to a web site on port 80 and having the site respond back on another port.
It just wouldn't work. If your vpn router is doing this then it is seriously
flawed.
2. The tftp server is supposed to respond from port 32800. The client then
attempts to connect back to the server on port 32800 but one of your vpn
routers is blocking that traffic. Is your ipsec tunnel setup to allow
packets on all ports in both directions?
What machine created that tcpdump output that you posted? Perhaps a quick
diagram of your network layout would be enlightening.
db
On Thu, Jun 12, 2008 at 5: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
>
-------------------------------------------------------------------------
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
