You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would expect this configuration to deny access to 192.168.1.5, but allow all other addresses in the 192.168 range. However, this is not what happens. The explicitly denied address is still allowed. This curl command:
{"allow":true,"conn_establish_time_ms":6,"content_length":928,"decision_reason":"Egress ACL is not configured","dns_lookup_time_ms":0,"enforce_would_deny":false,"id":"cs9eo7rjuspjjhc5lb70","inbound_remote_addr":"[::1]:57632","level":"info","msg":"CANONICAL-PROXY-DECISION","outbound_local_addr":"192.168.1.5:57633","outbound_remote_addr":"192.168.1.5:8000","proxy_type":"http","requested_host":"192.168.1.5:8000","start_time":"2024-10-18T23:15:43.082352Z","time":"2024-10-18T16:15:43-07:00","trace_id":""}
Interestingly, the inverse configuration using --allow-address and --deny-range works as expected. The below command allows requests to 93.184.215.14
I'm hoping to have more time to dig into this next week. Perhaps the issue is that the allow list is always being given precedence over the deny list? If so, its probably important to document how these rules are applied. It makes more sense to have the more specific options (--allow/deny-address) to take precedence.
The text was updated successfully, but these errors were encountered:
Hello! Playing around with smokescreen, I noticed a potential rough edge. I'm using this command line configuration:
I would expect this configuration to deny access to
192.168.1.5
, but allow all other addresses in the 192.168 range. However, this is not what happens. The explicitly denied address is still allowed. This curl command:results in these log lines:
Interestingly, the inverse configuration using
--allow-address
and--deny-range
works as expected. The below command allows requests to 93.184.215.14I'm hoping to have more time to dig into this next week. Perhaps the issue is that the allow list is always being given precedence over the deny list? If so, its probably important to document how these rules are applied. It makes more sense to have the more specific options (
--allow/deny-address
) to take precedence.The text was updated successfully, but these errors were encountered: