Re: relayd(8): transparent forward
On 2019-11-06 08:25, Stuart Henderson wrote: On 2019/11/05 20:46, Mischa Peters wrote: When you are using transparent (Direct Server Return) you have to make sure you disable ARP on the servers you are load balancing. Transparent is not "direct server return", that is done with "route to". What happens with transparant is that the server gets the client IP as source, not the IP of relayd, and will respond directly to the client from its own IP address. The client is expecting a response from the relayd IP address and doesn’t respond to the server. The client is expecting a response from the address it sent packets to, "transparent" doesn't interfere with this. There is something fiddly with the config for "transparent" but it should be possible to do what OP wants if relayd is on a machine on the network path between client and destination (e.g. on a firewall/router). relayd is on the same machine (on lo0:8443) as the destination (httpd on re0:443). Any ideas what might be missing?
Re: relayd(8): transparent forward
> On 6 Nov 2019, at 08:25, Stuart Henderson wrote: > > On 2019/11/05 20:46, Mischa Peters wrote: >> When you are using transparent (Direct Server Return) you have to make sure >> you disable ARP on the servers you are load balancing. > > Transparent is not "direct server return", that is done with "route to". You are right indeed. However according to the manual transparent also retains the client IP. So seems similar in operation, but I guess a different use-case. > >> What happens with transparant is that the server gets the client IP as >> source, not the IP of relayd, and will respond directly to the client from >> its own IP address. The client is expecting a response from the relayd IP >> address and doesn’t respond to the server. > > The client is expecting a response from the address it sent packets to, > "transparent" doesn't interfere with this. > > There is something fiddly with the config for "transparent" but it should > be possible to do what OP wants if relayd is on a machine on the network > path between client and destination (e.g. on a firewall/router). >
Re: relayd(8): transparent forward
On 2019/11/05 20:46, Mischa Peters wrote: > When you are using transparent (Direct Server Return) you have to make sure > you disable ARP on the servers you are load balancing. Transparent is not "direct server return", that is done with "route to". > What happens with transparant is that the server gets the client IP as > source, not the IP of relayd, and will respond directly to the client from > its own IP address. The client is expecting a response from the relayd IP > address and doesn’t respond to the server. The client is expecting a response from the address it sent packets to, "transparent" doesn't interfere with this. There is something fiddly with the config for "transparent" but it should be possible to do what OP wants if relayd is on a machine on the network path between client and destination (e.g. on a firewall/router).
Re: relayd(8): transparent forward
Mischa, as you were guessing right, my sole intention was to have the actual client IP address available on the server side without changing anything in the current server configuration. With your explanation, I understand that in my case this is not possible. So, as you suggested, passing the client IP to the server side by means of the 'X-Forwarded-For' header is the way to go. Thanks for your help. Matthias On 2019-11-05 20:46, Mischa Peters wrote: What are you trying to do? When you are using transparent (Direct Server Return) you have to make sure you disable ARP on the servers you are load balancing. What happens with transparant is that the server gets the client IP as source, not the IP of relayd, and will respond directly to the client from its own IP address. The client is expecting a response from the relayd IP address and doesn’t respond to the server. Since you are going to the same server it might not be a good idea to use transparent. :) If you want to get the client IP address on your destination you can add the client IP address in a header, if it’s HTTP. With headers like: match request header set "X-ClientIP" value "$REMOTE_ADDR" match request header append "X-Forwarded-For" value "$REMOTE_ADDR" match request header append "X-Forwarded-By" value "$SERVER_ADDR:$SERVER_PORT" Hope this helps. Mischa
Re: relayd(8): transparent forward
What are you trying to do?
When you are using transparent (Direct Server Return) you have to make sure you
disable ARP on the servers you are load balancing.
What happens with transparant is that the server gets the client IP as source,
not the IP of relayd, and will respond directly to the client from its own IP
address. The client is expecting a response from the relayd IP address and
doesn’t respond to the server.
Since you are going to the same server it might not be a good idea to use
transparent. :)
If you want to get the client IP address on your destination you can add the
client IP address in a header, if it’s HTTP.
With headers like:
match request header set "X-ClientIP" value "$REMOTE_ADDR"
match request header append "X-Forwarded-For" value "$REMOTE_ADDR"
match request header append "X-Forwarded-By" value "$SERVER_ADDR:$SERVER_PORT"
Hope this helps.
Mischa
--
> On 5 Nov 2019, at 17:38, mp1...@gmx-topmail.de wrote:
>
>
> The configuration below works fine as soon as I remove the 'transparent'
> keyword but times out when running as transparent forwarder.
>
> What am I missing?
>
> Any help is being appreciated.
>
>
> -
> # relayd.conf
>
> http protocol "httpsfilter" {
>tcp { nodelay, sack }
>return error
>pass
>tls keypair test-site
> }
> relay "httpsinspect" {
>listen on 127.0.0.1 port 8443 tls
>protocol "httpsfilter"
>transparent forward with tls to destination
> }
> --
>
> --
> # pf.conf
>
> set skip on lo
> block return
> pass
> pass in on egress inet proto tcp to port https \
>divert-to 127.0.0.1 port 8443
> --
>
>
> Here's some debug output:
>
> root:/root:2# relayd -dvv
> startup
> socket_rlimit: max open files 1024
> socket_rlimit: max open files 1024
> socket_rlimit: max open files 1024
> pfe: filter init done
> socket_rlimit: max open files 1024
> relay_load_certfiles: using certificate /etc/ssl/test-site.crt
> relay_load_certfiles: using private key /etc/ssl/private/test-site.key
> parent_tls_ticket_rekey: rekeying tickets
> relay_privinit: adding relay httpsinspect
> protocol 1: name httpsfilter
>flags: used, return, relay flags: tls, tls client, divert
>tcp flags: nodelay, sack
>tls flags: tlsv1.2, cipher-server-preference
>tls session tickets: disabled
>type: http
>pass request
> ca_engine_init: using RSA privsep engine
> ca_engine_init: using RSA privsep engine
> ca_engine_init: using RSA privsep engine
> ca_engine_init: using RSA privsep engine
> init_tables: created 0 tables
> relay_tls_ctx_create: loading certificate
> relay_tls_ctx_create: loading certificate
> relay_tls_ctx_create: loading certificate
> relay_launch: running relay httpsinspect
> relay_launch: running relay httpsinspect
> relay_launch: running relay httpsinspect
> relay_tls_transaction: session 1: scheduling on EV_READ
> relay httpsinspect, tls session 1 established (1 active)
> relay_connect: session 1: forward failed: Operation timed out
> relay_close: sessions inflight decremented, now 0
> relay_tls_transaction: session 2: scheduling on EV_READ
> relay httpsinspect, tls session 2 established (1 active)
> relay_connect: session 2: forward failed: Operation timed out
> relay_close: sessions inflight decremented, now 0
> ^Ckill_tables: deleted 0 tables
> hce exiting, pid 46061
> ca exiting, pid 45725
> flush_rulesets: flushed rules
> ca exiting, pid 26171
> ca exiting, pid 87096
> pfe exiting, pid 63649
> relay exiting, pid 69039
> relay exiting, pid 56446
> relay exiting, pid 69591
> parent terminating, pid 49439
> root:/root:3#
>
