Re: LAN -> LAN via External IP
"James Chase" If I fully understand your situation a lot of what you do depends on whether you intend to resolve names and whether you can use subnets. In my situation I have a number of servers and internal clients on different subnets with one external public IP address. pf obviously becomes trivial. The obvious issue is resolving zones you are authoritive for to internal clients. I've chosen to pass resolving onto the ISP partly to overcome this. If that's on the table as an option I recommend looking at this: http://www.openbsd.org/faq/pf/rdr.html#sepnet Once you do that, add a rule for your client subnet(s) that redirect any incoming on the corresponding internal_IF on your router to the appropriate server. That is: server ="192.168.250.1" vhosts ="58.108.203.117" pass in on pppoe0 inet proto tcp from any to (pppoe0) port www rdr-to $server pass out on xl0 inet proto tcp from any to $server port www pass in on dc0 inet proto tcp from dc0:network to $vhosts port www rdr-to $server pass in on rl0 inet proto tcp from rl0:network to $vhosts port www rdr-to $server Note vhosts can be any number of domains. Again it depends on different subnets and as far as resolving goes, public IPs can be returned and pf will take care of that. No other consideration necessary. As far as I understand it I was facing exactly the same decisions and made the sweeping decision to pass all resolving to the ISP. I have no over-riding security or performance consideration there and it seemed like a great idea to miss the fun of splitting DNS or screwing around with hosts files. Having a quick look at dhcpd.conf it might be possible to specify hosts from there. I expect it is but certainly doable by some other mechanism. I thought about chasing that down but in the end it didn't seem worth it. Best wishes.
Re: LAN -> LAN via External IP
On 2012-11-13, James Chase wrote:
> Also, is there some catch all that could be created with rules like this?
> Currently we are using this on specific services when we want to be able to
> use the fqdn on a local server without adding the internal ip resolution to
> /etc/hosts:
>
> rdr pass on {$ext_if, $int_if} inet proto tcp from any to $mx4_ext port 25
> -> $mx4_int port 25
>
> nat on $int_if inet proto tcp from 192.168.1.0/24 to $mx4_int port 25 ->
> $int_if
You don't need to specify port numbers if you want it to apply to
every port.
> It has the very much less than ideal result of showing the connection coming
> from the firewall internal interface though, which makes it harder to know
> where incoming connections are really coming from in the logs and such.
No way around this without some type of split-horizon DNS. If you're
redirecting, the packets *must* go back to the device doing that
translation otherwise the return packets from server->client will
have the wrong source address so the client will ignore them.
I usually try and put machines hosting rdr'd services on a separate
subnet to avoid this.. In cases where this isn't practical I usually
override the host records on a local name resolver.
LAN -> LAN via External IP
I'm trying to find the cleanest solution for correct routing of internal LAN
servers to the external IP's of other servers in the same LAN.
I have read the OpenBSD FAQ here
(http://www.openbsd.org/faq/pf/rdr.html#reflect ) and mostly understand the
problems associated with doing this via some relatively simple firewall
rule. The purpose of this is to simplify the logic in our pf rules a bit
where we have redirects/nat for the internal LAN clients (see below) but
also to allow access to internal services without always editing /etc/hosts.
I'm wondering what people think the cleanest way of accomplishing this is?
The split view DNS seems like kind of an extra management hassle and a good
opportunity to screw something up. But running a proxy and the added rules
in pf doesn't seem like a great solution either.
Also, is there some catch all that could be created with rules like this?
Currently we are using this on specific services when we want to be able to
use the fqdn on a local server without adding the internal ip resolution to
/etc/hosts:
rdr pass on {$ext_if, $int_if} inet proto tcp from any to $mx4_ext port 25
-> $mx4_int port 25
nat on $int_if inet proto tcp from 192.168.1.0/24 to $mx4_int port 25 ->
$int_if
It has the very much less than ideal result of showing the connection coming
from the firewall internal interface though, which makes it harder to know
where incoming connections are really coming from in the logs and such.
Anyways. Any thoughts?
