[squid-users] tcp_outgoing_address binds to wrong interface

Nick Rogers ncrogers at gmail.com
Mon Jun 29 20:54:33 UTC 2015


Hello,

I am experiencing an issue with squid 3.5.5 and FreeBSD 10.1 where
tcp_outgoing_address correctly rewrites the source address of outgoing
packets, but fails to bind the socket to the correct interface. I've been
using this kind of setup/configuration for quite some time (since the squid
2.7 days), so I believe something between squid 3.3 and squid 3.5 has
broken this behavior, or it is a problem with FreeBSD 10.x that I do not
understand. FWIW squid 3.3.3 on FreeBSD 9.x behaves correctly with the same
config.

I've been able to replicate this on a non-production VM with a simple
config. For example, I have two WAN interfaces: WAN1 (em0/192.168.92.246)
and WAN2 (em1/10.8.8.10), and a LAN interface (em2/192.168.5.1/24). My
default route points to the gateway for WAN1/em0. I have configured a
tcp_outgoing_address for a single host on the LAN (192.168.5.2) to use
outgoing address 10.8.8.10 (WAN2/em1). HTTP request packets from squid end
up going out em0 (the default route interface) with an ip of 10.8.8.10. The
source IP is correct but the packets egress the wrong interface, so they
are obviously dropped by the upstream router on that incorrect interface.

The following is my test squid.conf and some basic network config. While I
normally use squid as a transparent proxy in conjunction with the PF
firewall and routing enabled, for the purposes of replicating the issue in
my VM test environment I have disabled PF, routing, and connected directly
to squid via my browser's proxy config. Attempts to load webpages time out
unless I remove use of the tcp_outgoing_address directive.

# begin test squid.conf

acl SSL_ports port 443
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http
acl CONNECT method CONNECT

http_access allow localhost manager
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

http_access allow all

acl wan2 src 192.168.5.2
tcp_outgoing_address 10.8.8.10 wan2

follow_x_forwarded_for allow localhost
acl_uses_indirect_client on
log_uses_indirect_client on

http_port 3129

cache_replacement_policy heap LFUDA
maximum_object_size 768 MB
cache_dir aufs /squid/cache 2048 32 512

access_log      daemon:/squid/logs/access.log squid
cache_log       /squid/logs/cache.log
cache_store_log none

logfile_rotate 0

pid_filename /var/run/squid.pid

# end test squid.conf

em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
ether 00:0c:29:a3:33:93
inet 192.168.92.246 netmask 0xffffff00 broadcast 192.168.92.255
nd6 options=9<PERFORMNUD,IFDISABLED>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active

em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
ether 00:0c:29:a3:33:7f
inet 10.8.8.10 netmask 0xffffff00 broadcast 10.8.8.255
inet 10.8.8.11 netmask 0xffffff00 broadcast 10.8.8.255
inet 10.8.8.12 netmask 0xffffff00 broadcast 10.8.8.255
inet 10.8.8.13 netmask 0xffffff00 broadcast 10.8.8.255
inet 10.8.8.14 netmask 0xffffff00 broadcast 10.8.8.255
nd6 options=9<PERFORMNUD,IFDISABLED>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active

root# netstat -rn | grep default

default            192.168.92.2       UGS         em0

I am hoping someone can shed some light on whether or not this may be a
squid bug or something going on with FreeBSD. Thank you.

-Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20150629/1ec9c37a/attachment-0001.html>


More information about the squid-users mailing list