ibpalle

The problem with a default block, rather than a default allow is that there is so much content served up to web pages from different domain names. Content delivery, facebook like, twitter retweet, adverts, cookies .... A default block for anything not specifically allowed could remove bits of web pages due to background blocking of content from other domains. Sometimes that good (ads) sometimes it's not. There may need to be donme a bit of whack-a-mole to get some sites working correctly. For a locked down network I'd suggest ensuring HTTPS inspection is on and blocks in place for inappropriate categories.

There is a KB from MS on how to use Outlook web for 'dumb' devices. You find the links and short descriptions in our KB here: https://kb.smoothwall.com/hc/en-us/articles/360003683819

Have either of you raised any tickets with support and can you pm me the ticket numbers if you have?

Yes, the warning is to make sure it's understood that the outgoing traffic from the web proxy will now be treated as coming from the client, not the proxy. This means that the dropdown for Guardian traffic you can see in the Source NAT & LLB policies page, no longer applies.

Load average is generally a lot of disk activity. Logging, creating blockpages, indexing logs etc. The proxy limiter actually limits uploads to the clients, not downloads from the internet - arguably a better way of working and I'd recommend turning a generic one on for all users as that will allow the proxy to do fair distribution of bandwidth. Just note that the limit is set in Bytes, not bits. None of the methods have a major impact on CPU - proxy can distinguish between different types of web traffic, bandwidth cannot but can handle web as one and all other traffic types. That's the main difference.

Hmm, obviously a parser issue there - no time discernible on anything? Was thinking to go hunting for the actual log entry so see what it was.

Any specific tags or type of entry - user search or 'just' a URL?

Weird - is the Smoothwall up to date? We did have a formatting issue some time back which was corrected. When you get the blank email, is it blank or is it white on white e.g.?

We are likely addressing this in the Maiden update. Discussions are going on at the moment. Could possibly be done sooner - I'm pushing for it at least.

Best practise is really down to context in this case. If there is an already existing NPS install used for RADIUS auth, then keep using that - RADIUS accounting can then either be sent to the Smoothwall and forwarded from there to the NPS or the other way around. Forwarding on the Smoothwall is a bit easier to configure. If there's no existing RADIUS server, then use Smoothwall for both auth and accounting. Edit: BTW, the reason DHCP is sometimes in the mix is when there is no 'Framed-IP' attribute presented to the Smoothwall in the accounting packets. Smoothwall relies on that information to get the IP of the user to login. If it's not there, it can sometimes work if the Smoothwall is the DHCP server for the network as we can look at DHCP leases to find the MAC address and IP of the newly logged in user.

DHCP yes, the DHCP server on MS Servers have much better functionality. RADIUS - sure. If it's just for 802.1x and BYOD< Smoothwall is easy to use for both auth and accounting.

Spoofing preserves the client IP for web traffic leaving the proxy. Normally source IP for proxied traffic would be the proxy IP itself. If you were only using the filter, not the firewall, you would have to be sure to make all return traffic route back into your network via the Smoothwall, otherwise spoofing breaks things. When you use both firewall and filter on the same device, spoofing can be used as return traffic is always routed back via the Smoothwall. Bandwidth shaping can then be done based on client IP as that process takes place before the final NAT. The reason for using spoofing here is so we can apply bandwidth limits on web traffic based on client IP.

We had hoped this issue had been addressed in an earlier update - think it was one in the thirties but apparently not. Getting rid of the mac1x chain will prevent this from happening - possibly the new features on iOS and Android with dynamic MAC addresses is causing problems as well when paired with the mac1x functionality.

If you are trying to shape client traffic on the external interface using the clients internal addresses, you won't get a match as the traffic will be NATted externally. Further, a lot of this traffic would be wen traffic so it may be easier to impose a bandwidth limit in the web proxy section instead. If you are using the Smoothwall as both firewall proxy you can enable spoofing on the web proxies, which will preserver the client IP after it leaves the proxy. Then the bandwidth module will apply based on client IP - after the bandwidth shaping comes the final NAT rule in the firewall so client IP is natted correctly for internet based traffic.

Make sure the firewall rules allow outgoing on the ipsec interfaces as well on the main site.

The routing setup to achieve this could be to have all site subnets within one range and then have a tunnel from each site to the main where the target subnet is the supernet for all sites, like this: Main site: 192.168.1.0/24 Branches: 192.168.2.0/24, 192.168.3.0/24 etc Each branch has one tunnel to main which is defined as a tunnel to 192.168.0.0/16 This setup only requires one tunnel at each site, connected to the main smoothwall.

Looks like the PFSense is using IKEv2 - have you enabled IKEv2 on the Smoothwall tunnel? I would suggest not using IKEv2 on the PFSense or the Smoothwall. Other than that, it's a matter of making sure the 2 have the same encryption settings - show a screenie of the settings for each tunnel and I may be able to assist further.

We do have a verbose logging option for the auth engine - needs to be enabled in the services - authentication - settings menu, however it does not specifically show the inner workings of an NTLM or Kerberos transaction, just the replies the auth system receives regarding user info. Is this happening for all systems or just for some? Also, I'd recommend you take a look at our iDex solution for domain user identification instead - so many applications use HTTPS these days and close to none of them support NTLM or Kerberos - you can get rid of a lot of headache by moving to iDex.

If the clients on the network is using Smoothwall as DNS then yes, you should be able to add the hostname to the Smoothwall DNS override.

Just a note that the URL now can also be reached on http://ip.of.smoothwall/getcert

Chaplics suggestion would seem to be the right one if you cannot change the proxy settings. Would be nice if NHS devices could use automatic proxy discovery - that would allow you to setup the wpad alias for the Smoothwall and have the laptop dynamically adjust proxy settings based on location but ...

Looks like the category Video Filetypes are being blocked. You should be able to allow this by adding 'vod-adaptive.akamaized.net' without quotes to the 'URL patterns' field in an allow category.

You can get authentication using Google accounts but it's a manual process with a redirect to the login page. There is no transparent login possible with android in the same way we can do with Chromebooks unfortunately.

The 407 error is proxy authentication required. Most likely you are using NTLM or Kerberos for proxy auth and one or more of the elements using the proxy when you are going to code academy is not capable of providing proxy authentication. Bypassing authentication for the target domains is an option but I would suggest you look at changing the auth methods used - Smoothwall has a new iDex system which solves most of those issues and would be a good feature to implement in general as a lot of apps use HTTPS these days but rarely support any form of proxy authentication. Contact your account manager and have them setup a rework to look at implementing iDex - it's not difficult to design and implement so won't take more than 2-3 hours to configure and test.

Theres no detailed logging of the RADIUS messages available in the UI but you can run a debug command and check the output there on the console. Log on to the console and run the command: radiusdebug --run You can pipe this to a text file if you find the info is passing by too fast. Once you have the debug info, stop this by using ctrl+c and then restart the radius service from the UI by just editing and saving one of the RADIOUS client entries in services - authentication - BYOD.