Skip to content

--allow-ranges/--deny-address combination does not work as expected #236

@eastebry

Description

@eastebry

Hello! Playing around with smokescreen, I noticed a potential rough edge. I'm using this command line configuration:

./smokescreen --listen-port 8888 --allow-range '192.168.0.0/16' --deny-address '192.168.1.5'

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:

curl --proxy http://localhost:8888 http://192.168.1.5:8000/

results in these log lines:

{"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

./smokescreen --listen-port 8888 --deny-range 93.0.0.0/8 --allow-address 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions