On Tue, 6 Jun 2017 12:05:10 -0500
Ax0n <a...@h-i-r.net> wrote:

> Also, this seems like something that, depending on where the
> destination servers are, could be handled easily with PF by itself,
> or with the help of relayd, with a lot less hassle.

Perhaps I didn't explain what I use this for. I have a vlan on private
subnet, which has no access to other private vlans - it can contact
only Internet hosts. One of "Internet" hosts is actually IP alias on
external interface of my OpenBSD firewall, which redirects (rdr-to)
internal host on my LAN:

pass in on $if_ext inet proto tcp from any to $pub_srv port $web \
   rdr-to $priv_srv

Now, as redirection happens to packets which are incoming to external
interface, above rule does not hit for packets coming from internal
vlan. 

That's why I combine pf redirection on internal interface to
loopback:
pass in quick on $if_int inet proto tcp from <privnets> to $pub_srv \
   port 80 rdr-to 127.0.0.1 port 20080
pass in quick on $if_int inet proto tcp from <privnets> to $pub_srv \
   port 443 rdr-to 127.0.0.1 port 20443

... and proxy these packets with nc from inetd:
127.0.0.1:20080 stream tcp nowait _nc_proxy /usr/bin/nc \
   srv-http -w 20 PRI.VAT.EAD.DR 80
127.0.0.1:20443 stream tcp nowait _nc_proxy /usr/bin/nc \
   srv-https -w 20 PRI.VAT.EAD.DR 443

I know that simple rdr on internal interface doesn't work out of the
box - I would probably need some kind of NAT, as LAN server wouldn't
return packet to firewall from where it was redirected - it would try
to contact LAN client directly, and fail (isolated VLAN).

Now as for relayd, I never used it. If someone gave me working example
and an explanation why it is better than my current solution, I'd be
glad to switch, and pass the word around :)

Thank you all for tips and hints.
-- 
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Reply via email to