[squid-users] tcp_outgoing_address directive ignored, data goes out on default gateway

[Amos Jeffries]

On 26/11/2022 11:49 pm, N wrote:
> Hi,
> I'm trying to use tcp_outgoing_address to forward traffic from 
> specific users to a specific interface.
>
> running squid 5.7 (on openwrt).
> have a few interfaces on my machine, two of which are VPN interfaces 
> with IPs (internal) 10.200.0.70  and10.102.237.50.
> trying to forward user "uk" to the interface with IP 10.200.0.70 is 
> "ignored" - I can see that the default WAN interface is used. I see it 
> by using a simple "what is my ip" test when using the proxy, and 
> checking the traffic of the interfaces when sending requests.
>
> the relevant excerpt from the squid conf:
> acl auth_users proxy_auth REQUIRED

First possibility:

  Authentication is a VERY slow process. It is definitely not reliable 
to trigger during a 'fast' type ACL check like tcp_outgoing_* directives.

To fix this you need to ensure authentication is performed in 
http_access or similar early 'slow' access control directive. eg.

    http_access deny !auth_users


Squid can then access the username with a 'note' type ACL check like so:

   acl wg_uk note user uk


> acl wg_uk proxy_auth uk
> tcp_outgoing_address 10.200.0.70 wg_uk
>
> I can see that the IP and config are not wrong because the requests 
> don't get 503 errors (if I change the IP to a non existing one, e.g. 
> 10.200.0.71 I do get 503 errors).
>

The log snippet looks like Squid is correctly obeying your configuration:

> small excerpt from the squid_cache.log (proxy server is 192.168.1.1, 
> proxy client is 192.168.1.149)
> 2022/11/26 11:28:48.286| 17,3| FwdState.cc(394) Start: 
> 'http://detectportal.firefox.com/canonical.html'
> 2022/11/26 11:28:48.286| 17,2| FwdState.cc(157) FwdState: Forwarding 
> client request conn157 local=192.168.1.1:3128 
> <http://192.168.1.1:3128> remote=192.168.1.149:64723 
> <http://192.168.1.149:64723> FD 13 flags=1, 
> url=http://detectportal.firefox.com/canonical.html

To be clear, the above are about the client<->Squid connection which 
triggered this outbound request.

...
> 2022/11/26 11:28:48.287| 14,4| ipcache.cc(647) 
> ipcache_nbgethostbyname_: ipcache_nbgethostbyname: HIT for 
> 'detectportal.firefox.com <http://detectportal.firefox.com>'
> 2022/11/26 11:28:48.287| 14,7| ipcache.cc(250) forwardIp: 34.107.221.82
> 2022/11/26 11:28:48.287| 28,5| Acl.cc(124) matches: checking wg_uk
> 2022/11/26 11:28:48.287| 28,3| Acl.cc(151) matches: checked: 
> tcp_outgoing_address 10.200.0.70 = 1
> 2022/11/26 11:28:48.287| 28,3| Checklist.cc(63) markFinished: 
> 0x7ffd71e3d440 answer ALLOWED for match
> 2022/11/26 11:28:48.287| 44,2| peer_select.cc(1171) handlePath: 
> PeerSelector27 found conn167 local=10.200.0.70 remote=34.107.221.82:80 
> <http://34.107.221.82:80> HIER_DIRECT flags=1, destination #1 for 
> http://detectportal.firefox.com/canonical.html

As you can see Squid MAY select to use a connection where the local= IP 
is your configured tcp_outgoing_address ...

...
> 2022/11/26 11:28:48.288| 14,7| ipcache.cc(250) forwardIp: 
> [2600:1901:0:38d7::]
> 2022/11/26 11:28:48.288| 44,7| peer_select.cc(1149) 
> interestedInitiator: PeerSelector27
> 2022/11/26 11:28:48.288| 44,2| peer_select.cc(1171) handlePath: 
> PeerSelector27 found conn168 local=[::] remote=[2600:1901:0:38d7::]:80 
> HIER_DIRECT flags=1, destination #2 for 
> http://detectportal.firefox.com/canonical.html

... or it also MAY select IPv6 which you did not configure any 
particular address for.
In accordance with with BCP 177 specifications Squid prefers IPv6 when 
possible setting up new connections.
This can also be impacted by "happy eyeballs" timing and whether there 
is an existing open connection on either of those two routes to the server.

So it is most likely that the IPv6 was chosen when you see the "not 
working" behaviour with 10.200.0.70 address, and the IPv4 is chosen when 
you saw the 503 errors in the 10.200.0.71 tests.


Try adding tcp_outgoing_address for IPv6 first and see if the problems 
disappear completely.

The log shown stops before showing which of the two connections were 
actually used, so there may be additional problems later. If they remain 
we will need more log info to tell what is going on. Including the debug 
11,2 trace of a non-working transaction would help.


Cheers
Amos