Welcome to the Community!
Your setup sounds correct (in all aspects that you described). Can you verify that the Web Gateway itself can ping the internet (18.104.22.168)? You can do this from the GUI under Troubleshooting > Network Tools or from the CLI.
I ask this because the MWG should not be modifying DNS, so your problem sounds more like an issue with the network configuration (even though it looks pretty straight forward).
Hope you are doing well.
Is their a route present on router to send traffic back for 172.28.10.0/24 network?
Router will see the 172.28.10.0 traffic and needs to know that 10.10.0.2 will accept the responses to get the data back to client.
Below is an overview of transparent router config on MWG:-
1. Define 2 network interface in web gateway
2. Enable transparent router mode
3. Add http in port redirect
4. Enable http and ftp proxy
5. Save and restart web gateway
Below is overview of tarffic flow
Client (172.28.10.10) --> MWG eth0 (172.28.10.1, Default GW for clients) - MWG eth1 (10.10.0.2) --> Router (10.10.0.1, Default GW for MWG) --> Internet
If you explicitly configure MWG as your proxy on the client the clients won't have any trouble talking to MWG. MWG will talk from 10.10.0.2 (the interface connected to its Default GW (the router)) to get out to the Internet. The router sees packets from a direct neighbor and will reply data back to MWG - All good.
In transparent mode MWG receives a packet from the client 172.28.10.10. It is routed to eth0 and leaves on eth1. Now on the router there is a packet from source IP 172.28.10.10. MWG does not perform Address Translation or anything but will simply route the packets. In such an environment you will need to manually teach the router that all packets from 172.28.10.0/24 need to be routed back to MWGs leg that the router is connected to (10.10.0.2). Once the router forwards the packet back to MWG the subnet (172.28.19.0/24) is known to MWG and the data can get back to the client.
Transparent: The browser/client is NOT "proxy aware". The client will try and directly communicate with its destination. The client requests need to be intercepted/redirected on their way to the destination to reach the Web Gateway. As the client is not aware of the Web Gateway or its filtering, all correspondance needs to "look like" it is still happening with the original destination server. Functionality that is normally available to proxies (like authentication) cannot be used in their normal fashion. MWG offers WCCP, Transparent Router and Transparent Bridge as transparent deployment options.
Often times a transparent deployment is chosen mainly because Administrators do not want to have to make browser changes. Unfortunately this is a common misconception and in reality changes often DO need to be made to browsers (see table below). In addition, transparent deployments often add MORE complexity to the deployment and require more work on the Administration side.
Please refer below link for more info:-