The journal doesn’t seem to make any mention of socks - maybe my logging level isn’t set low enough?
Did you add a secondary IP to one nic or did you add a second nic to that EC2?
Maybe - I am prety verbose 
kumo.set_diagnostic_log_filter 'kumod=debug'
we have kumo hosted in aws and the proxy server in the data center. the proxy server has 1 nic with several IPs associated with it. each one of the ips on the proxy server is mapped to a wan ip so when the proxy server binds on .101, .102, etc there’s a wan ip that is associated with each
AH, ok
hmm… I know this is not what you want to hear, but “it works for me”
socks5_proxy_server: Some(54.218.75.124:5000), socks5_proxy_source_address: Some(172.31.20.96), ttl: 60s } egress_pool="pool-3"
socks5_proxy_server: Some(54.218.75.124:5000), socks5_proxy_source_address: Some(172.31.27.74), ttl: 60s } egress_pool="pool-3"
I think that just means we need to look in another place if you are not seeing the same thing.
^^ this is 2 IPs on one NIC in a dedicated socks5 proxy in AWS.
NOT the same as you have with the external physincal NIC which coudl make some difference
hmm interesting - and do they exit using the correct associated wan IP? Because the config “worked” - in that it said it bound to the other source_address - it just didn’t
checking the headers of the delivered mail now
and it totally could be just some weirdness with how socks works with my particular firewall configuration
I’ve even had weirdness where a second NIC never got used because the assigned IPs were routable from the first NIC
OK, I can confirm that I am seeing the same thing. Took a lot of digging but I do see it.
The proxy is set up with 2 private and 2 public IPs on one NIC. When I send messages through the proxy, the private IPs do round-robin, but they always route from the first public IP.
I will create a bug ticket and escalate it. Thank you so much for bringing this to our attention.
Great! Thank you Tom for digging in on that with me!!! 
Sorry, have been a bit distracted today (folks in town). I took a quick peek at this, and I think there’s a line missing from the proxy:
; git diff
diff --git a/crates/proxy-server/src/proxy_handler.rs b/crates/proxy-server/src/proxy_handler.rs
index 388aaeb5..5f7558e3 100644
--- a/crates/proxy-server/src/proxy_handler.rs
+++ b/crates/proxy-server/src/proxy_handler.rs
@@ -171,6 +171,7 @@ async fn handle_request(
SocketAddr::V6(_) => TcpSocket::new_v6(),
}?;
+ socket.bind(host)?;
let addr = socket.local_addr()?;
*state = ClientState::Bound(socket);
I haven’t tried to run any of this, but it does pass cargo check.
@free-spirited-yorksh boom that seems to have done the trick!
works as expected with that code change
it’s a real egg-on-face moment TBH. That’s literally the most important part of the server
