Matt Carey(cvstealth2...@yahoo.com) 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
>
--
