socks5 source address

Hey team! I’m missing something and could use a fresh set of eyes. I have kumomta routing to kumo-proxy to a server that has LAN ips bound to various WAN ips. However, I’m not able to get kumo-proxy to send out any local ip other than the primary.

snippet from sources.toml:

[source."ip-1"]
socks5_proxy_server = 'x.x.x.x:5000'
socks5_proxy_source_address = 'x.x.x.101'
ehlo_domain = 'mta1.xxx.xxx'

[source."ip-2"]
socks5_proxy_server = 'x.x.x.x:5000'
socks5_proxy_source_address = 'x.x.x.102'
ehlo_domain = 'mta2.xxx.xxx'

I have kumo-proxy running: cargo run --release -- --listen=0.0.0.0:5000

And when I telnet and bind to x.x.x.101 or x.x.x.102 the correct WAN ip is used. However, when using kumo-proxy, x.x.x.101 (the nic default) is always used even when ip-2 is being used with socks5_proxy_source_address = 'x.x.x.102'

Roast me for what I’m missing and thanks for the help!

Hey there @veracious-mule, thanks for posting. Please read the “Troubleshooting” and “How to Ask for Help” buttons below. If you would like a 1:1 support session from the KumoMTA team, details are at the “Book a Support Session” button below.

Running some local testing now - what you have done looks right to me at first glance.

what does your pools config look like?

I suppose the first things to verify are:

  1. Are you definitely assigning an egress pool that uses ip-2?
  2. Is there anything in the kumo journal about the proxy?
  3. In your delivery (or transient failure logs), does it mention anything about the proxy?
  4. If you try using curl with the proxy, does that succeed?
  5. Is there anything logged by the proxy process? If you run it with RUST_LOG=proxy_handler=trace it should log more info about what it is doing
[pool."pool-1"]
[pool."pool-1"."ip-1"]
[pool."pool-1"."ip-2"]

I’ve also done just:

[pool."pool-1"]
[pool."pool-1"."ip-2"]

to force ip-2

looking at the logs now to answer your questions

  1. As best as I can tell. If I set ip-2 as the only ip the logs show it being used.
  2. No mention of the proxy in the journal
  3. It shows egress_pool and egress_source but nothing specific mentioning a proxy
  4. I haven’t tried with curl but I’ll take a look at that
  5. I’ll run trace logs on the proxy as well

not seeing any log output when running RUST_LOG=proxy_handler=trace cargo run -- --listen=0.0.0.0:5000

are you definitely assigning the pool to that tenant/message?

I believe so. Port 25 isn’t even open on the host machine (aws ec2) and if I remove all other ips and leave just the ip-2 it shows in the logs as ip-2 but still proxies out the primary interface ip on the socks server.

Couple of log lines will help there.

I’ve gotta run for now so I’ll ping you guys when I’m back - thanks for taking a look at this with me

In my testing, I am able to route to pool-1 and pool-2 using the queues helper and an X-Tenant header through a the socks5 proxy. it seems to work as designed.
I have NOT tried sending high volume mail through to see if it round-robins, but I am not sure if that is really your question.

My “sources” file:

# Pool Definitions
[pool.'pool-0']
[pool.'pool-0'.'ip-0']

[pool.'pool-1']
[pool.'pool-1'.'ip-1']

[pool.'pool-2']
[pool.'pool-2'.'ip-2']

[pool.'pool-3']
[pool.'pool-3'.'ip-1']
[pool.'pool-3'.'ip-2']

# Egress IP Definitions

[source.'ip-0']
source_address = '172.31.28.8'

[source."ip-1"]
socks5_proxy_server = '54.218.75.124:5000'
socks5_proxy_source_address = '172.31.28.8'
ehlo_domain = 'mta1.kumomta.com'

[source."ip-2"]
socks5_proxy_server = '54.218.75.124:5000'
socks5_proxy_source_address = '172.31.28.8'
ehlo_domain = 'mta2.kumomta.com'

I am using the same IP for both pools, but I think the issue you were having was that it was not selecting pool 2, and I was able to do that

{ name: "ip-2", ehlo_domain: Some("mta2.kumomta.com"), source_address: None, remote_port: None, ha_proxy_server: None, ha_proxy_source_address: None, socks5_proxy_server: Some(54.218.75.124:5000)

and same for mta 1 (pool 1) separately

Can you please confirm if the problem you are seeing is that you are unable to route through pool2 to the proxy? Maybe I am misunderstanding the issue

I also just tested this with “pool-3” in the example above with multiple messages in the same connection and it did indeed round robin between those IPs.