Linux instance vs Windows instance - different behaviour in an AWS private subnet routing traffic through a NAT

I'm experimenting with a NAT gateway vs a Squid proxy in an EC2 instance (both of these placed in the same public subnet). To test connectivity, I'm using a private subnet to access the internet (once using a Linux instance, and then again using a Windows instance). The actual switch (squid vs NAT) is being done in the route table entry.

In other words, I test the following 4 combinations:

1. Linux instance + NAT Gateway
2. Linux instance + Squid proxy
3. Windows instance + NAT Gateway
4. Windows instance + Squid proxy

I see a difference in behaviour between the 2 instances. It looks like Windows is "sticky" and doesn't recognize that the routing has changed. When I change the routing from Squid to NAT, I can see that curl commands start working in the linux instance, but browser access does not in the Windows instance.

Here's the sequence of steps. The actual setup is listed after this.

Sequence of steps

1. Setup squid using the Ssl peek-and-splice feature to allow some sites and block others
2. Update route table so that traffic flows from private subnet > squid eni
3. Try curl in Linux. Response shows Squid is present.
4. Open a browser in Windows and go to the URL. Response shows Squid is present.
5. Update the route table so that traffic flows from private subnet > nat gateway
6. Try curl in Linux. Response shows we have internet access.
7. Open a browser in Windows and go to the URL. Response still shows Squid is present.

VPC Details (condensed to only the subnets in question)

1. Public subnet has both the NAT gateway as well as the EC2 instance that runs squid

2. Security groups have been set to allow HTTP and HTTPS traffic inbound and all traffic outbound

3. Each subnet has its own route table association

4. 0.0.0.0/0 in the public subnet points to the internet gateway

5. 0.0.0.0/0 in the private subnet points to 1 of the below resources:

   i. To the NAT gateway

   ii. The ENI of the EC2 instance that runs squid

Screenshot of how it looks when it's pointing to Squid:

Squid proxy setup details

I'm trying to run squid as a transparent proxy but something's messed up. I get a curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL error. Nevertheless, it shows that squid is running and intercepting traffic.

Conf:

visible_hostname squid
cache deny all

# Log format and rotation
logformat squid %ts.%03tu %6tr %>a %Ss/%03>Hs %<st %rm %ru %ssl::>sni %Sh/%<a %mt
logfile_rotate 10
debug_options rotate=10

# Handle HTTP requests
http_port 3128
http_port 3129 intercept

# Handle HTTPS requests
https_port 3130 cert=/etc/squid/ssl/squid.pem ssl-bump intercept
acl SSL_port port 443
http_access allow SSL_port
acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3
ssl_bump peek step1 all

# Deny requests to proxy instance metadata
acl instance_metadata dst 169.254.169.254
http_access deny instance_metadata

# Filter HTTP requests based on the allowlist
acl allowed_http_sites dstdomain "/etc/squid/allowlist.txt"
http_access allow allowed_http_sites

# Filter HTTPS requests based on the allowlist
acl allowed_https_sites ssl::server_name "/etc/squid/allowlist.txt"
ssl_bump peek step2 allowed_https_sites
ssl_bump splice step3 allowed_https_sites
ssl_bump terminate step2 all

http_access deny all

iptables:

iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3129
iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 3130

Instance details

1. Linux: Amazon Linux EC2 instance in private subnet. No public IP. Private IP DNS enabled.
2. Windows: Windows 10 setup through AWS WorkSpaces in private subnet. Security group hasn't been changed and is as provisioned by WorkSpaces.

The misconfigured Squid proxy shows up differently when comparing Linux curl vs Windows browser:

1. For Linux curl, I always get an OpenSSL SSL_connect: SSL_ERROR_SYSCALL, irrespective of whether I'm trying to access a blocked URL or an allowed URL.
2. For Windows browser, I get a PR_END_OF_FILE_ERROR if the URL isn't in the allow-list. If it is in the allow-list, then access occurs without issues.

How do I understand what's happening here? Shouldn't the Windows instance also route traffic to the NAT gateway when the route tables change?