Matt Carey([email protected]) on 2013.12.17 05:22:12 -0800: > In an attempt to use relayd as an outbound http "proxy", which is just needed > to do URL filtering rather then content caching, I'm finding that the outbound > connections are being sourced from the IP of the external interface of the > firewall rather then the carp interface that the pf NAT rules are using for > other traffic. > > For example if the following IP scheme is used/pf rules are > in place: > ext_if="1.1.1.1" > carp_if="1.1.1.2" > int_if="172.31.1.1" > match out on > $ext_if inet from $int_if:network to any nat-to 1.1.1.2 label "NAT [OUT] - > Desktop" > pass in log quick on $int_if proto tcp from $int_if:network to any > port http divert-to 127.0.0.1 port 8080 > > /etc/relayd.conf: > http protocol > httpfilter { > ??????? return error > ??????? label "URL filtered!" > ??????? > request url filter "www.example.com/" > } > > relay httpproxy { > ??????? listen on > 127.0.0.1 port 8080 > ??????? forward to destination > } > > When the divert line in > /etc/pf.conf is commented out then the traffic on the WAN/external interface > is sourced from 1.1.1.2, however when the traffic is diverted to relayd then > the traffic is sourced from 1.1.1.1. Ideally I'd like the traffic to source > from the typical NAT interface, as when the carp interface is failed over to > the peer firewall those sessions in the state table are preserved.
having the pf state on the other machine isn't going to help you here: with a relay, you are in layer 7 and your userland socket won't be there to forward the traffic. So your connection is going to be stuck at that point anyway. /Benno > With squid I found that this can be accomplished by using the > tcp_outgoing_address attribute to force the traffic to be sourced from a > given address. > > Any > help/advice would be appreciated. > > Regards, > Matt > --
