Scheduled maintenance on Saturday, August 8th from 7am to 10am (UTC). Licensing registrations and key activations will be unavailable during this period. More info here.

PXE Boot DONE!

Hello everyone!

Since documentation on pxe booting on XG is (at least) gray, I've finally found a solution that works for me and opened this discussion to share ideas or success stories if it's working for others.

First of all, we'll need to login to the console of the XG.  There are 2 ways for that:

1) On the webpage of the XG, click on your name(probably admin) on the top right corner and click console. It will ask for password and then to press enter to show the console menu

2) Via SSH(eg. putty). Remember your username is not root if you're used to it, it's admin!

After that, we get to the same menu for both. A list with numbers to select for settings. We press 4 to enter Device Console.

Once we're in the Console, we'll need to know 3 things. The name of the DHCP server(the default is Default_DHCP_Server, the Tftp-server IP and the bootfile. My case let's say it's Default_DHCP_Server, tftp ip is10.10.10.148 and the bootfile is pxelinux.0 
You can find the name of the DHCP Server clicking Network->DHCP on the sfos web page.
We enter these 2 commands:

system dhcp dhcp-options binding add dhcpname Default_DHCP_Server optionname TFTP_Server_Name(66) value 10.10.10.148

system dhcp dhcp-options binding add dhcpname Default_DHCP_Server optionname Bootfile_Name(67) value pxelinux.0

Notice that although all the manuals and other people used brackets on the values(eg. 'pxelinux.0'), I didn't. Don't know if it's better, but since it's working this way, I didn't touch it!

Close the console. At this point, you should get an ip address when you try to boot from lan, but will not boot to the environment, although you should. I believe the problem lies the XG doesnt like to forward to another server, although it now knows there's a pxe boot.

Next step is to go to the web page of the XG and go to Firewall -> Add Firewall Rule ->Business Application Rule

Application Template "Full Nat/DNAT/Load Balancing"

Position "Top"

Enter the rule name you want (eg. TFTP)

Source "LAN" - Allowed Client Networks "ANY"

Destination "10.10.10.1" (Your routers address. DO NOT use the ones with a # in front. We'll need it for later! Probably you don't have it, so create one. Name it Sophos and put its address)

Services add one with port UDP 69 and one with port UDP 4011

Protected Servers "10.10.10.148" (your pxe servers address. add it if you don't have it)

Protected Zone "Lan"

Next click Rewrite Source Address "Masquerading" and click the one with the rules name(in my case it was #TFTP). Do not use MASQ

Finally click create reflexive rule and save the rule.

Voila! For me anyways.

I tested this with Clonedeploy and FOG and it boots.

  •  

    Maybe something for an KBA? 

  • In reply to LuCar Toni:

    Hi  

    Thanks for sharing this with our community!

    @LuCar Toni - I'll forward this over to our KB team for their consideration :)

    Best,

  • In reply to FloSupport:

    You're very welcome! :)

    Actually, I'd rather for the community to test it first so we can be sure it's a global solution rather than a personal one before posting a KB, but sure.

    Enterprise-wise though, it should already be implemented on the web adminstration page. In my opinion, being able to backup and deploy machines on demand and remotely is a crucial feature for an IT who wants his head not sweating! With PXE we can set which machines will we backed up on next boot and if a machine breaks down, we can program to deploy the previous machine's image to the new pc without the need to go back and forth to the companies. It will make our lives a lot easier!

  • In reply to Panagiotis Vakerlis:

    Regarding the topic of having this configured via the GUI web admin page, this is a suggestion that our product team is continually evaluating to slot into our existing roadmap.

    For added context, here are the existing KBA's we currently have regarding configuring DHCP options on the XG (through CLI).

    Regards,

  • In reply to FloSupport:

    Well, let's hope it's coming on next release! Cause doing all this work just for pxe is ok for openwrt, but for a web-based next-gen firewall...you get my point.

  • PXE boot dhcpd options are built in defaults.  

    Also there should be no reason to use a business rule / dnat.  There are no special requirements within XG that tftp should be handled by a business rule. A regular network rule and routing will work just fine.

    Thank you for going through the steps and documentation I just wanted to clear up what is needed in general pxe cases.

    console> system dhcp dhcp-options list

    TFTP_Server_Name(66)                                        String

    Bootfile_Name(67)                                           String

    Mobile_IP_Home_Agent(68)                                    Array of IP-Address

    SMTP_Server(69)                                             Array of IP-Address

    ….

    • Defining the pxe option 66 server address value and binding the dhcpd server:

    console> system dhcp dhcp-options binding add dhcpname Default_DHCP_Server optionname TFTP_Server_Name(66) value '10.125.125.96'
    DHCP option TFTP_Server_Name(66) added for DHCP Server Default_DHCP_Server.

    • Defining the image to boot and associating it to the dhcpd server.

    console> system dhcp dhcp-options binding add dhcpname Default_DHCP_Server optionname Bootfile_Name(67)  value 'goldimage.img'
    DHCP option Bootfile_Name(67) added for DHCP Server Default_DHCP_Server.

     

  • I've tested this and it doesn't work for WDS or SCCM PXE.

    Two problems: 

    The XG business application rule does not limit its matching to the services specified, so all traffic destined for your PXE server gets NATed, not just the port 69 and 4011 traffic. Additionally, all traffic coming from the PXE server gets NATed as well, even when it shouldn't be. Why you need to bother specifying services if it's going to match everything anyway is bizarre and infuriating.

    Most PXE clients absolutely need the next-server value specified. With the NAT rule in place, I do get the initial file from the TFTP server, but there is a referral in the response that instructs PXE to get other files and the client will then try to get the file from the server specified in DHCP. Since next-server isn't (and can't be) specified, the client tries to get it from 0.0.0.0 which is invalid and doesn't exist (and the XG will not allow you to create a NAT rule to forward traffic destined for 0.0.0.0).

    Why is the ability to configure next-server missing? Isn't this a core, standard part of the DHCP server specification?

    My Sophos rep pushed me hard to switch from UTM to XG and I'm very, very disappointed with the XG firewalls for this and a number of other issues.

  • In reply to asander:

    Hey asander, you might try this again but set the Bootfile_Name(67) as this: tftp://<server's_IP_address>/<filename> instead of just the filename. I was using just the filename and it worked with one type of VM. I figured this was because that VM client would assemble the path on-the-fly but I've found that's not the case with all devices. I've been testing it using another VM and a hardware netbook. I have found that one VM worked with just 'pxelinux.0' as Bootfile_Name(67) but the other VM and netbook would not. I just tried changing it to a network path 'tftp://<my server's IP>/pxelinux.0' and all of them work!!

  • In reply to Greg Grotsky:

    Thanks for the suggestion. It got me a little closer. It's able to download the PXE file but since the TFTP server is on another subnet, it still fails on the referral. Without the ability to set the next-server configuration, it still tries to get the next file from 0.0.0.0.

  • In reply to asander:

    First of all, sorry for being away for some time.

    As I've mentioned, I wrote this to look for feedback. See if it's a global solution or a personal. No need to get cranky on something I've already declared to be a personal solution.

    Second to that, the business rule imitates next-server. For me at least. I've had the same problem for the next-server going to 0.0.0.0 and not loading the menu and when I created the business rule, it worked. Wrong or right, it worked and didn't have any side effects for my setup. 

    However, after one full year of ACTIVELY using this, I have to say that it's not working on all machines. Maybe it's a Clonedeploy problem (It throws an error TFTP bootfile is too long). But I've setup a few machines as cloners and they work flawlessly. On other machines it's trial-and-error.

    With your pxe server being out of the subnet, I can't help with that.

  • In reply to Panagiotis Vakerlis:

    Any way to get updated instructions for V18? They have changed the way dnat/snat/business rules get created. 

    Trying to mobilize a remote work group and wanted to pxe boot remotely but its not working for me. 

    It tries to reach 0.0.0.0 and it fails.

    Any help would be greatly appreciated. 

    Thanks

    Gus

  • If have not use it for a heck of a while ... Quite frankly, loading a fresh ISO XG and uploading a backup is so quick I wonder the purpose of it. 

    I used to boot windows desktops with PXE.  It brings this question: why don't you PXE boot from within the BIOS ?

    Paul Jr