Discussion:
npf and ephemeral interfaces (tun0)
(too old to reply)
David Brownlee
2016-02-17 15:26:55 UTC
Permalink
I have a server which needs to run an npf map rule on its OpenVPN
interface (tun0).

I can create the rule fine, but when the system restarts tnpf rejects
the rulset because there is no tun0 interface. Am I missing something?
Is there a way around this?

I have a couple of other systems still using pf to avoid this kind of issue :/

Relevant rule lines:

$vpn_if = inet4(tun0)
map $vpn_if dynamic $foohost port 22 <- $foohost port 24

Thanks

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Tobias Nygren
2016-02-17 15:57:04 UTC
Permalink
On Wed, 17 Feb 2016 15:26:55 +0000
Post by David Brownlee
I have a server which needs to run an npf map rule on its OpenVPN
interface (tun0).
I can create the rule fine, but when the system restarts tnpf rejects
the rulset because there is no tun0 interface. Am I missing something?
Is there a way around this?
I do "ifconfig tun0 create" in /etc/netstart.local combined with
"openvpn --persist-tun" to prevent it from removing the interface on
reconnect.

-Tobias

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Manuel Bouyer
2016-02-17 17:21:07 UTC
Permalink
Post by Tobias Nygren
On Wed, 17 Feb 2016 15:26:55 +0000
Post by David Brownlee
I have a server which needs to run an npf map rule on its OpenVPN
interface (tun0).
I can create the rule fine, but when the system restarts tnpf rejects
the rulset because there is no tun0 interface. Am I missing something?
Is there a way around this?
I do "ifconfig tun0 create" in /etc/netstart.local combined with
"openvpn --persist-tun" to prevent it from removing the interface on
reconnect.
that's not a workaround applicable to all cases.
For example on a Xen dom0 guest interfaces can't be pre-created
(and also the name changes over time, but that's another issue)
--
Manuel Bouyer <***@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Christos Zoulas
2016-02-17 19:35:46 UTC
Permalink
Post by David Brownlee
I have a server which needs to run an npf map rule on its OpenVPN
interface (tun0).
I can create the rule fine, but when the system restarts tnpf rejects
the rulset because there is no tun0 interface. Am I missing something?
Is there a way around this?
I have a couple of other systems still using pf to avoid this kind of issue :/
$vpn_if = inet4(tun0)
map $vpn_if dynamic $foohost port 22 <- $foohost port 24
Although you can refer to non-existing interfaces and they will work inspite
of the warnings, I have:

pass final on ppp0 all
pass final on ppp1 all
pass final on ppp2 all

inside my rules without having any ppp interfaces at filter load
time, unfortunately refering to addresses on a non-existing interface
does not work. Having the ability to insert and remove map statements
like this dynamically is a missing feature that also makes UPNP
difficult to implement.

christos


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
David Brownlee
2016-02-17 20:57:35 UTC
Permalink
Post by Christos Zoulas
Post by David Brownlee
I have a server which needs to run an npf map rule on its OpenVPN
interface (tun0).
I can create the rule fine, but when the system restarts tnpf rejects
the rulset because there is no tun0 interface. Am I missing something?
Is there a way around this?
I have a couple of other systems still using pf to avoid this kind of issue :/
$vpn_if = inet4(tun0)
map $vpn_if dynamic $foohost port 22 <- $foohost port 24
Although you can refer to non-existing interfaces and they will work inspite
pass final on ppp0 all
pass final on ppp1 all
pass final on ppp2 all
inside my rules without having any ppp interfaces at filter load
time, unfortunately refering to addresses on a non-existing interface
does not work. Having the ability to insert and remove map statements
like this dynamically is a missing feature that also makes UPNP
difficult to implement.
Thanks - setting "$vpn_if = tun0" looks like it should work for this
specific case, which is a relief. I think I have another
currently-pf-using box which may need the ip on the ephemeral
interface, but at least one other box will also be happy with this, so
thats at least 2/3 wins right away :)

Thanks again!

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Darren Reed
2016-03-07 14:48:56 UTC
Permalink
Post by Christos Zoulas
Post by David Brownlee
I have a server which needs to run an npf map rule on its OpenVPN
interface (tun0).
I can create the rule fine, but when the system restarts tnpf rejects
the rulset because there is no tun0 interface. Am I missing something?
Is there a way around this?
I have a couple of other systems still using pf to avoid this kind of issue :/
$vpn_if = inet4(tun0)
map $vpn_if dynamic $foohost port 22 <- $foohost port 24
Although you can refer to non-existing interfaces and they will work inspite
pass final on ppp0 all
pass final on ppp1 all
pass final on ppp2 all
inside my rules without having any ppp interfaces at filter load
time, unfortunately refering to addresses on a non-existing interface
does not work. Having the ability to insert and remove map statements
like this dynamically is a missing feature that also makes UPNP
difficult to implement.
Are there any active UPNP projects for NetBSD?
Or just porting miniupnpd?

At some point in the past what you're describing (dynamic NAT rules
managed byminiupnpd)worked with ipf but that was a long time ago now.
Relatively speaking.

Cheers,
Darren



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Loading...