Hello, Well this is not so simple as it looks but I have made success with traceroute.
route -T1 exec '/usr/sbin/traceroute' -n route -T2 exec '/usr/sbin/traceroute' -n route -T3 exec '/usr/sbin/traceroute' -n Goes out on proper gateways so it works. For Squid things gets a little bit more complicated. For example I use squidguard which is spawned by squid so I don't know if the alternative routing table applied to this as well. |-+= 03951 root /usr/local/sbin/squid | \--- 06369 _squid (squid-1) --kid squid-1 (squid) When I start squid I get: route -T3 exec '/usr/local/sbin/squid' 2019/06/26 14:50:35| WARNING: (B) '127.0.0.1' is a subnetwork of (A) '127.0.0.1' 2019/06/26 14:50:35| WARNING: because of this '127.0.0.1' is ignored to keep splay tree searching predictable 2019/06/26 14:50:35| WARNING: You should probably remove '127.0.0.1' from the ACL named 'localhost' 2019/06/26 14:50:35| WARNING: (B) '127.0.0.1' is a subnetwork of (A) '127.0.0.1' 2019/06/26 14:50:35| WARNING: because of this '127.0.0.1' is ignored to keep splay tree searching predictable 2019/06/26 14:50:35| WARNING: You should probably remove '127.0.0.1' from the ACL named 'localhost' 2019/06/26 14:50:35| WARNING: (B) '::1' is a subnetwork of (A) '::1' 2019/06/26 14:50:35| WARNING: because of this '::1' is ignored to keep splay tree searching predictable 2019/06/26 14:50:35| WARNING: You should probably remove '::1' from the ACL named 'localhost' 2019/06/26 14:50:35| WARNING: (B) '::1' is a subnetwork of (A) '::1' 2019/06/26 14:50:35| WARNING: because of this '::1' is ignored to keep splay tree searching predictable 2019/06/26 14:50:35| WARNING: You should probably remove '::1' from the ACL named 'localhost' 2019/06/26 14:50:35| WARNING: (B) '127.0.0.0/8' is a subnetwork of (A) '127.0.0.0/8' 2019/06/26 14:50:35| WARNING: because of this '127.0.0.0/8' is ignored to keep splay tree searching predictable 2019/06/26 14:50:35| WARNING: You should probably remove '127.0.0.0/8' from the ACL named 'to_localhost' 2019/06/26 14:50:35| WARNING: (B) '0.0.0.0' is a subnetwork of (A) '0.0.0.0' 2019/06/26 14:50:35| WARNING: because of this '0.0.0.0' is ignored to keep splay tree searching predictable 2019/06/26 14:50:35| WARNING: You should probably remove '0.0.0.0' from the ACL named 'to_localhost' 2019/06/26 14:50:35| WARNING: (B) '0.0.0.0' is a subnetwork of (A) '0.0.0.0' 2019/06/26 14:50:35| WARNING: because of this '0.0.0.0' is ignored to keep splay tree searching predictable 2019/06/26 14:50:35| WARNING: You should probably remove '0.0.0.0' from the ACL named 'to_localhost' 2019/06/26 14:50:35| WARNING: (B) '::1' is a subnetwork of (A) '::1' 2019/06/26 14:50:35| WARNING: because of this '::1' is ignored to keep splay tree searching predictable 2019/06/26 14:50:35| WARNING: You should probably remove '::1' from the ACL named 'to_localhost' 2019/06/26 14:50:35| WARNING: (B) '::1' is a subnetwork of (A) '::1' 2019/06/26 14:50:35| WARNING: because of this '::1' is ignored to keep splay tree searching predictable 2019/06/26 14:50:35| WARNING: You should probably remove '::1' from the ACL named 'to_localhost' 2019/06/26 14:50:35| ERROR: Directive 'url_rewrite_concurrency' is obsolete. 2019/06/26 14:50:35| WARNING: url_rewrite_concurrency upgrade overriding url_rewrite_children settings. I see that this might be an issue of the loopback not being present on that table so I have added: route -T3 add -net 127.0.0.0/8 127.0.0.1 route -T3 add -host localhost localhost route -T3 show Routing tables Internet: Destination Gateway Flags Refs Use Mtu Prio Iface default 192.168.10.252 UGS 0 5 - 8 vio0 127/8 localhost UGS 0 1 32768 8 lo0 localhost localhost UGHS 0 0 32768 8 lo0 IPV4 I don't need. Maybe I did not add the localhost correctly?! since if I compare this with the main routing table I see different flags: 127/8 localhost UGRS 0 0 32768 8 lo0 localhost localhost UHhl 3 98 32768 1 lo0 Anyway Squid starts with the mentioned warnings but any request I try to make through it hangs. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, June 24, 2019 11:07 AM, Claudio Jeker <cje...@diehard.n-r-g.com> wrote: > On Mon, Jun 24, 2019 at 08:47:38AM +0000, slackwaree wrote: > > > Hello, > > Could you maybe provide a full case study for this as it is fairly > > uncommon task? > > Do you mean that I will also need +2 ip aliases next to the boxes main ip? > > No. You can use either option. The question is how are the proxy users > talking to those 3 different proxies? If you want to use port 8080 for all > of them you want 3 different IPs. > > > Eg instead of > > 192.168.10.1: 3128 3129 3130 > > 192.168.10.1:3128 using gateway 192.168.10.250 > > 192.168.10.2:3128 using gateway 192.168.10.251 > > 192.168.10.3:3128 using gateway 192.168.10.252 > > Try it out yourself. Create an extra table and run a proxy in it. > Use tools like tcpdump, nc, etc to check if it works. > > Start with: > route -T1 add default 192.168.10.250 > route -T1 exec "squid command to run ideal with debugging on" > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > :wq Claudio > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On Friday, June 21, 2019 8:27 PM, Brian Brombacher > > brian.brombac...@planetunix.net wrote: > > > > > You’ll also need PF rules to allow incoming traffic from your squid > > > clients to go to the routing table where your squid process is running. > > > > > > > On Jun 21, 2019, at 10:28 AM, Claudio Jeker cje...@diehard.n-r-g.com > > > > wrote: > > > > > > > > > On Fri, Jun 21, 2019 at 02:11:53PM +0000, slackwaree wrote: > > > > > Hello, > > > > > I wonder if the following scenario can be solved with OpenBSD on 1 > > > > > single machine or with VMM: > > > > > I got 3 OpenBSD vms, all of them are exactly the same running squid > > > > > except they use different default routers to route their traffic out. > > > > > I would like to merge these to one VM if it is possible somehow to > > > > > tell OpenBSD to use different gateway depending on the squid process. > > > > > If not would the same thing be possible with VMMs? All the gateways > > > > > are in the same IP range. > > > > > > > > A simple way to solve this is with multiple routing tables. > > > > Create multiple routing tables with: > > > > route -T1 add default <gw1> > > > > route -T2 add default <gw2> > > > > route -T3 add default <gw3> > > > > And start the 3 squid processes with route -T1 exec, route -T2 exec. > > > > You can also use the the *_rtable variable in rc.d(8) to do that > > > > automatically. > > > > This requires that the 3 squids listen on different IPs or ports. > > > > > > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > > > > > > > :wq Claudio
