Re: Router with WAN subnet - dedicated IP per Host

2019-11-26 Thread Stuart Henderson
On 2019-11-26, Henry Jensen  wrote:
> On Tue, 26 Nov 2019 12:27:16 - (UTC)
> Stuart Henderson  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.
>
>
>
>



Re: tmux: How to create a new window with the same path (from the current pane)

2019-11-26 Thread Anders Damsgaard

* Atanas Vladimirov  [2019-11-26 17:10:14 +0200]:

So, if I understand your example right, I need to do something like 
`bind c new-window -c "$PWD"` in my .tmux.conf.
The problem is that it works partially - if I'm in 
`/home//` and start tmux there,
the $PWD is correct, but when I change the directory and create a new 
window with `C-b c` it moves me to the initial $PWD (when the tmux was 
started)

instead of the current directory.


I don't bind in .tmux.conf, but you could do:

bind c send-keys "tmux new-window -c \"$(pwd)\"" C-m
bind C send-keys "tmux split-pane -c \"$(pwd)\"" C-m

but it needs a shell prompt in the currently active pane.

Cheers, Anders



Re: tmux: How to create a new window with the same path (from the current pane)

2019-11-26 Thread Atanas Vladimirov

On 2019-11-26 16:27, Anders Damsgaard wrote:

* Atanas Vladimirov  [2019-11-26 14:27:33 +0200]:


Hello,

The following works on Linux:

```
bind c new-window -c "#{pane_current_path}"

```

but the `pane_current_path` variable does not exists on OpenBSD.
Does anyone now how can I achieve the same behavior on OpenBSD?


Hi Atanas,

I recently asked Nicolas Marriott the same question on Freenode/#tmux. 
The

pane_current_path functionality is disabled on OpenBSD because of
security reasons.

For that reason I added the following function to my ~/.profile.  
However,

it does not enable splitting without sending current processes to
background:

tsplit() {
if [ -z "$TMUX" ]; then
echo "error: not in tmux session" >&2
return 1
fi
if [ $# -gt 0 ]; then
if [ "$1" = "v" ]; then
tmux split-pane -v -c "$PWD"
elif [ "$1" = "h" ]; then
tmux split-pane -h -c "$PWD"
elif [ "$1" = "w" ]; then
tmux new-window -c "$PWD"
else
echo "error: split direction not understood" >&2
return 2
fi
else
tmux split-pane -h -c $PWD
fi
}

Best, Anders


Hi Anders,

Thanks for your reply.
So, if I understand your example right, I need to do something like 
`bind c new-window -c "$PWD"` in my .tmux.conf.
The problem is that it works partially - if I'm in 
`/home//` and start tmux there,
the $PWD is correct, but when I change the directory and create a new 
window with `C-b c` it moves me to the initial $PWD (when the tmux was 
started)

instead of the current directory.

Does anyone know how to make it work as I desire, or it's not possible?
Thanks in advance,
Atanas






Re: tmux: How to create a new window with the same path (from the current pane)

2019-11-26 Thread Anders Damsgaard

* Atanas Vladimirov  [2019-11-26 14:27:33 +0200]:


Hello,

The following works on Linux:

```
bind c new-window -c "#{pane_current_path}"

```

but the `pane_current_path` variable does not exists on OpenBSD.
Does anyone now how can I achieve the same behavior on OpenBSD?


Hi Atanas,

I recently asked Nicolas Marriott the same question on Freenode/#tmux. The
pane_current_path functionality is disabled on OpenBSD because of
security reasons.

For that reason I added the following function to my ~/.profile.  However,
it does not enable splitting without sending current processes to
background:

tsplit() {
if [ -z "$TMUX" ]; then
echo "error: not in tmux session" >&2
return 1
fi
if [ $# -gt 0 ]; then
if [ "$1" = "v" ]; then
tmux split-pane -v -c "$PWD"
elif [ "$1" = "h" ]; then
tmux split-pane -h -c "$PWD"
elif [ "$1" = "w" ]; then
tmux new-window -c "$PWD"
else
echo "error: split direction not understood" >&2
return 2
fi
else
tmux split-pane -h -c $PWD
fi
}

Best, Anders
--
Anders Damsgaard
https://adamsgaard.dk



Re: Router with WAN subnet - dedicated IP per Host

2019-11-26 Thread Henry Jensen
On Tue, 26 Nov 2019 12:27:16 - (UTC)
Stuart Henderson  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.

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.





tmux: How to create a new window with the same path (from the current pane)

2019-11-26 Thread Atanas Vladimirov

Hello,

The following works on Linux:

```
bind c new-window -c "#{pane_current_path}"

```

but the `pane_current_path` variable does not exists on OpenBSD.
Does anyone now how can I achieve the same behavior on OpenBSD?

Many thanks,
Atanas



Re: Router with WAN subnet - dedicated IP per Host

2019-11-26 Thread Stuart Henderson
On 2019-11-25, Henry Jensen  wrote:
> Hi,
>
> my ISP provides me with a /29 subnet, including 5 usable public IPv4
> addresses.
>
> Until now my router uses only one of this public IPs (11.22.33.40),
> with port forwarding of port 443 to an host in a DMZ(192.168.1.0/24)
> like this:
>
>  pass in on egress proto tcp from any to any port 443 rdr-to 192.168.1.2
>
> Now I plan to have a second host in the DMZ which should use another
> public IP from the subnet the ISP gave me.
>
> In other words, I want to do the following
>
> 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?

How is your internet connection provided? If the subnet is routed to your
router IP (as, for example, would always be the case with a PPP-based
connection) then you don't actually need to configure the second IP on
your router, making it easy to achieve this.

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".

(If it's ethernet and there's a separate "link" subnet then the main
public IP subnet would probably be routed via the link subnet, in which
case they would only be ARPing for the link network IP, so same applies
as with PPP, you could just not configure the IP).

If none of this seems to fit then describe your setup in more detail
(ifconfig -A and netstat -rn or similar).

> Do I have to use rtables and rdomains or is there a simpler approach?

I don't think that would be needed.