On 2019-11-26, Henry Jensen <hjen...@mailbox.org> wrote:
> On Tue, 26 Nov 2019 12:27:16 -0000 (UTC)
> Stuart Henderson <s...@spacehopper.org> wrote:
>
>> > 192.168.1.2  < rdr-to/nat-to > 11.22.33.40
>> > 192.168.1.3  < rdr-to/nat-to > 11.22.33.41
>> >
>> > I plan to give the outgoing interface the second public IP
>> > (11.22.33.41) as an alias, so the egress interface holds both
>> > public IP addresses. Question is, how do I do the routing so that
>> > DMZ host 192.168.1.3 uses public IP 11.22.33.41 exclusively?  
>> 
>> I read this as "how do I make it so that *only* the DMZ host uses
>> 11.22.33.41 and the router itself doesn't use it", is that right?
>
> Yes, but first and formost, 192.168.1.3 should use *only* 11.22.33.41
> as gateway, 192.168.1.2 (and posibly other hosts) should use 11.22.33.40
> as gateway.

But 192.168.1.3 isn't in the 11.22.33.x network itself is it? So it
can't use 11.22.33.*anything* as gateway because it has no way to reach
it directly..

> Both, 192.168.1.2 and 192.168.1.3, are in the DMZ. 192.168.1.2 is a
> webserver and 192.168.1.3 is mail/smtp server. Therefore is is crucial,
> that 192.168.1.3 is using only 11.22.33.41 as gateway, because of
> DNS/RDNS. 
>
>
> With Linux/iptables one would establish different routing tables, "mark"
> the packages and then set "ip rule" and SNAT rules accordingly. I find
> this procedure over-complicated, so I was hoping for a simpler
> approach with OpenBSD/pf.
>
>
>> If it's ethernet-like and the subnet has ISP router, your router,
>> plus your public IPs, then usually the ISP would be ARPing for
>> addresses so in that case you need to have some way that your router
>> will respond to those requests. The simplest way is indeed to add the
>> address to the interface, if you want to prevent local traffic using
>> that address then maybe a PF rule generally blocking traffic with
>> that address, and another to permit it "received-on $dmz_if".
>
> The entire public subnet is routed through the ISP router (11.22.33.39)
> which belongs to the same subnet.
>
>
>
>

Reply via email to