PF Interface name that changes

ogogon

ogogon

Colleagues, please tell me what is the best thing to do in my case.

I have a router that has several VPNs. They use interfaces like tunXX. Sometimes some links are disconnected, while others are connected at the same time. Consequently, the tunnel number of a link in the one direction may change.

How can I link this direction to the rules written for it in pf.conf?

At the moment the tunnel is connected, a script is triggered that knows the current interface name, but how can I correctly associate it with the rules in the PF config?

Thanks in advance,
Ogogon.
 
covacat said:
look at pf / pfctl anchors
Click to expand...
Something else worries me - I don’t really understand how I can carry out full dynamic interaction of my program (script) with the PF.

For example, if I need to enable NAT on the interface and I issue the commands:
sh: 
echo "nat on $TUNDEV inet from !($TUNDEV) -> ($TUNDEV:0)" | pfctl -Ef -
echo "rdr pass on $TUNDEV proto tcp to port 3333 -> 192.168.1.1 port ssh" | pfctl -Ef -
most likely, the necessary rules will be added and everything will work correctly.

But I don’t understand how to cancel these two rules when the tunnel is disconnected.
 
I am pretty sure devd might come of use here.
Code: 
I resolved the issue by creating a devd conf file:

$ cat /etc/devd/tun.conf
# Run PF when tun0 is up
notify 0 {
match "system" "IFNET";
match "subsystem" "tun0";
match "type" "LINK_UP";
action "/etc/rc.d/pf start";
};

You would want to do something similar like trigger a LINK_DOWN script..
 
Another way to consider is have two different configuration files.(pftunup.conf//pftundown.conf)
Instead of reloading rules, load a different named rule set file for your tun UP/DN condition.
 
ogogon said:
most likely, the necessary rules will be added and everything will work correctly.
Click to expand...
That is the part I don't like about piping text to pfctl.
Would make separate config files UP/DN like above and reload pf with -F.
Maybe trigger action via devd and LINK_UP / LINK_DOWN

Perhaps get deluxe and add feedback loop looking for confirmation pf reloaded.

pf: interface flags reset
Click to expand...
 
Phishfry said:
You would want to do something similar like trigger a LINK_DOWN script..
Click to expand...
Perhaps I didn't describe my problem very clearly. The OpenConnect VPN client has a completely acceptable hook mechanism, and tracking changes in link states is not problematic.
The problem is how, having received information that the VPN-link is turned on or off, change the PF settings.
 
Phishfry said:
Another way to consider is have two different configuration files.(pftunup.conf//pftundown.conf)
Instead of reloading rules, load a different named rule set file for your tun UP/DN condition.
Click to expand...
If I understood your recommendation correctly, then should I reload all PF settings every time the VPN client’s state changes? What if there are several of these clients?
 
I was just spitballing ideas.

ogogon said:
having received information that the VPN-link is turned on or off, change the PF settings.
Click to expand...
So this comes back to devd right? It is a mechanism you could use to trigger a script.

I gave you some different options (opinions?) from changing the name of the pf configuration file to simply writing over pf.conf with a script and reload pf.

I am probably speaking above my paygrade but I figure I would throw out some ideas.
 
Is it technically possible to use another method?
For each of my OpenConnect clients, I create a personal interface that does not participate in the life cycle of “regular” tun-type interfaces. I give them individual names, for example - oc0, oс1, etc.
Since the names are known in advance, I prescribe PF rules for them that do not require changes on the fly.
And then, I launch OpenConnect, indicating to it “his” personal interface.
 
Phishfry said:
I got a chuckle from this...
Click to expand...
But all this is no longer funny to me.
For some reason this VPN is gaining popularity, but its integration with FreeBSD is still somewhat imperfect.
I already have patches for the source code, but the author of the client and the BSD maintainer do not respond to email. In addition, it is not very clear how to beautifully integrate this client with a firewall.
 
I did not mean to taunt you. The pages I read all referenced Linux.
Maybe the person who ported the program has no idea how to use it.
Or lack of time...
 
You must log in or register to reply here.
Back
Top