@sebastian-roth said in Fog client installation error - Cannot install CA certificate:

@jonhwood360 Ok, here you go for another try: https://github.com/FOGProject/fog-client/releases/download/0.12.0/FOGService_enable_TLS12.msi

See if it can successfully pin to the FOG server with that and post a picture of the FOGService.install log as well.

Keep in mind, this is not for official deployment for various reasons.

We have a winner!

So it seems that newer apache does not like the 1.0 connections.

@sebastian-roth said in UEFI boot loop issue:

@jonhwood360 Some hardware/firmware is just not playing nicely when chainload the OS from disk. While rEFInd is your best call for UEFI based systems we do see this making problems on come hardware.

Take a look at this post: https://forums.fogproject.org/post/141390

Thanks for the references. Updating the refind x64 binary and making the following changes to the conf file seemed to work for my vmware vm:

timeout 5
scanfor internal,external,manual,netboot
scan_delay 5

@george1421

By and large I agree with you about the hash algorithm being irrelevant, however, some entities have requirements for minimum acceptable hashing for such kind of verification. I think a baseline of a choice between md5 and shasum baseline is fine, especially while development of the feature is ongoing (md5 is still widely used in forensics), however that will not always be the case and building support in for additional options might be better. The time cost involved is something the end user should accept when they select the additional complexity.

Just as a test, I timed sha 512 on my Windows 10 image. Here is the results:

Took about 2m 8s for 8 GB give or take. So the wait isn’t terrible at higher algorithm complexity. This test was done with a two virtual processor VM on a server with a bunch of other vms running.

Interestingly enough, the shasum utility on ubuntu can compare hashes to a text file for verification.

Also, I don’t think the hash need be taken inline with the imaging process, but be done post imaging, either on demand, or run in background automatically before image is made available for distribution.

Thoughts?

@tom-elliott said in Feature Request for FOG 1.6.X - Add image integrity verification check:

@jonhwood360
I’ll try to document better:

• 1. Why would we use this per host? Unless you mean per server containing images?

Sorry, I meant image, not host. However since fog does potentially have a distributed architecture, maybe a hash per image per image repository?

@tom-elliott I will assist as I am able to as per our private conversation. I agree a plugin would be good. Here are my thoughts:

• Plugin should probably allow the hash algorithm to be defined per image. That way a range of security requirements could be met. A drop down of available algorithms maybe?
• I agree with the database, although would this be a totally new database separate from the main fog one? If so I would wonder about query complexity and displaying that information on the image page in the gui?
• Does fog have a scheduler built in for timed tasks? If so, the plugin could maybe piggyback off of that to address the
  periodic update requirement

@george1421 Exactly, although I’d like to have the option for the algorithm used for the hash be user defined. I know some people may want Sha512, where as for some MD5 is sufficient for this purpose. A default of sha256 probably would be good as its more than the minimum (md5) but not as intense as 512.

edited: because I typed host instead of image. sorry for the confusion if any

Hi all,

One item I would like to see added is for when an image is captured for FOG to take a hash of some kind of the image files, and then have a view in the gui where you can see those hashes, and potentially ask it to do a check for those files against the captured hashes to verify they have not changed. The idea is so that if the image is altered outside of the image capture process, (as may be done by a hacker), the image could be flagged as changed outside of the normal capture process and would need to be hard overridden to be deployed.

Perhaps also a periodic check for image integrity as well with results that can be seen in the gui.

@george1421 said in Issue with EFI through PFSense Firewall:

@jonhwood360 said in Issue with EFI through PFSense Firewall:

so one thing I keep seeing in the packet capture which is weird, is that the router option (3) is set to 10.255.252.1 which is the gateway that the fog server uses, but is not the gateway for the external network. .

Well lets think about this for a minute. When I looked at the packet capture I did notice the lease times were different too.

Looking at the config file you provided both the lease times and route address are set correctly. Why are we seeing a difference in the packet captures from the configuration. Its almost like we have a different dhcp server for bios than uefi. Or two instances running with different config files on the FOG server.

Yep. The only thing I can figure is that somehow either the DHCP Relay or Arp Proxy in Pfsense is doing something weird, or the DHCP server is not processing my second range definition in its entirety (which is weird because booting into an OS proper, the exchange happens normally and gets the right settings).

Although in the mean time I have had to move along in my research so I moved the DHCP/ Bind DNS to PFsense and have configured it to have the correct options. EFI boot from fog server is working in this new configuration. I am leaving the existing configuration in place on the fog server though to return to this issue (which I think has value to try and solve).

@george1421

so one thing I keep seeing in the packet capture which is weird, is that the router option (3) is set to 10.255.252.1 which is the gateway that the fog server uses, but is not the gateway for the external network. .

and I figured out why the tftp-server-name line you gave me didn’t work. It was expecting a dns name, not an IP, there is a tftp-server-address option, which I set and did work (config loaded). This did not change anything though.

@george1421 said in Issue with EFI through PFSense Firewall:

@jonhwood360 But I assume it still doesn’t boot.

So without the config file alterations you don’t get the screen about filesize 0 bytes, but with the alterations you get that error. Just thinking about it a bit more I think we are on the right direction, maybe just not the right path.

Did you get a workstation pcap of the process where you received the 0 bytes filesize? I’m interested to know if dhcp options 66 and 67 were being set, where it was actually kind of working. If they were there with those settings and the settings were the key for EFI DHCP booting then we just need to work on why the settings were wrong. I didn’t get a chance last night to test this in my home lab where I have a ubuntu server to understand why the settings stopped isc-DHCP from booting. But I’ll look at it tonight if we can’t get it sorted out. The commands I gave you were from the isc-DHCP config file.

No no, I get the same error, just without the unprintable character.

So, yes option 66 (next-server) and 67 (filename) are being set. If I set the Endpoint VM to BIOS, it works fine in the external network.

If I put the endpoint in the same network as the DHCP server, both EFI and BIOS works fine.

I’ll check to make sure the DHCP settings between internal subnet and external subnet are the same (sans the obvious IP changes)

Thanks again for helping!

@george1421 said in Issue with EFI through PFSense Firewall:

@jonhwood360 OK I know this now. That unprintable character is what is causing the issue. I see that in some “university” dhcp servers. Let me look at your pcap again.

Just a note, once I reverted my config to my original without alterations, that character went away.

@george1421 said in Issue with EFI through PFSense Firewall:

Between next-server and class insert this line
option tftp-server-name 10.255.252.5;

Then for every instance of “filename…”; just below that line enter
option bootfile-name “<boot_file>”;

Where <boot_file> matches the boot file name issued by the filename command.

George,

Just wanted to take a moment to thank you for helping to troubleshoot this with me.

I did as you requested.

if the “option tftp…” line is enabled the dhcp server will fail to start. Isn’t it the case for isc-dhcp-server that the “next-server …” line is the equivalent?

if I disable the next-server line and just use “option tftp” it also fails to start:

if I leave the “option boot-file…” lines in and leave “next-server…” on and “option tftp…” off, the server starts

However there is no difference in boot either in a VM, or hardware. I did however snag this screenshot (sorry for the glare) from the laptop which might shed some light.

I then reverted my dhcpd.conf to without the changes you recommended and confirmed the same result, sans the square at the end of the filename. Still same PXE error.

So it appears that the dhcp exchange for EFI mode on the computers are happening, they are getting the right configuration data, but the data is getting mangled at some point.

Any thoughts?

@george1421 said in Issue with EFI through PFSense Firewall:

@jonhwood360 Well this pcap was unremarkable, other than we can see that there is no tftp download of the ipxe.efi file.

I did find something interesting looking at the previous pcap. For a bios computer the lease time is 6 hours, for a uefi the lease time is 4 hours. Once might think that if you are using the same dhcp server the lease time should be the same.

Now looking at the two offer packets side by side the values are identical, but I did notice something that could cause the issue. If you look at the picture below. Only the bootp protocol fields have been populated in the offer packet. What is missing is the dhcp boot protocol using dhcp options 66 and 67. The problem is its up to the target computer firmware which fields it wants to look at bootp or dhcp. Most dhcp servers that support pxe booting will populate both parts. This is because the client could chose bootp or dhcp.

So is this dhcp server configured by FOG or did you hand configure this dhcp server? The FOG configuration “should” provide both boot protocols.

The DHCP server was configured by fog, and I duplicated the entry for the internal subnet, and changed the relevant fields for the external one (attaching the conf).

Also I took another pcap, just with the EFI boot, but from both FOG and pfsense(External). (attached).

fogserver-EFI-timed-exchange.pcap
pfsense-EFI-timed-exchange-EXTERNAL-interface.pcap
dhcpd.conf.txt

Also, in the original pcap from the fogserver, only transaction ID 0xe25c58da is the EFI PXE exchange. The options you pointed out are set for that transaction as:

The other two transactions are when the initial tftp happens from the BIOS boot rom, and then the loading of iPXE it looks like.