Re: {obsd,pf}-faq.txt are greatly missed
Hi, Vasily Kolobkov wrote on Mon, Mar 07, 2016 at 05:20:56PM +0200: > as of not long ago the plain text versions of the faqs went missing > from http://www.openbsd.org/faq/{obsd,pf}-faq.txt > > wonder if that's for good? Yes. They were deleted to reduce maintenance burden and to avoid the risk of getting outdated. We'd rather have developers focus on improving the system and the authoritative documentation than maintaining multiple copies of auxiliary documentation. > those where really handy at times. A package like converters/html2text should to the trick for you whenever you need a plain text version. Yours, Ingo
{obsd,pf}-faq.txt are greatly missed
as of not long ago the plain text versions of the faqs went missing from http://www.openbsd.org/faq/{obsd,pf}-faq.txt wonder if that's for good? those where really handy at times.
Re: obsd pf
On 2014-03-18, Marko Cupać marko.cu...@mimar.rs wrote: On Tue, 18 Mar 2014 01:15:16 + (UTC) Stuart Henderson s...@spacehopper.org wrote: The ruleset is now traversed in order, changes made in match rules are sticky and affect rules lower down in the ruleset. More predictable, no more oh this 'nat pass' rule which you included halfway down the ruleset actually takes effect before the 'block quick' rule right at the top... so besides allowing for cleaner rulesets, you could say it's a security fix too. I am using new syntax for years now, and although there are a lot of improvements, there is also downside. I have /24 public network, where I need to have one catch all NAT rule, but also exceptions (smtp servers translate to other public IPs, vpn clients to their own public IPs etc). If I have a lot of subnets behind NAT firewall, I need to specify them all for catch all NAT rule, listing exceptions (this is of course shortened, actually I need to declare 100 or so networks and dozens of exceptions): table catchallnat { 10.20.69.0/24 10.43.26.0/22 \ !10.20.69.15 !10.43.26.29 } smtp = { 10.20.69.15 } vpn = { 10.43.26.29 } ... match out on $ext_if inet from catchallnat to any nat-to $catchallnat match out on $ext_if inet from $smtp to any nat-to $smtp-nat match out on $ext_if inet from $vpn to any nat-to $vpn-nat I don't know if there would be negative consequences for other pf aspects, but for me it would be better if more specific match rules overrided more general match rules. This way I would not have to maintain catchallnat table with list of subnets and exceptions. Just put your catchall rule *after* the others. | Subsequent rules will see packets as they look | after any addresses and ports have been translated. ^
Re: obsd pf
On Tue, 18 Mar 2014 01:15:16 + (UTC) Stuart Henderson s...@spacehopper.org wrote: The ruleset is now traversed in order, changes made in match rules are sticky and affect rules lower down in the ruleset. More predictable, no more oh this 'nat pass' rule which you included halfway down the ruleset actually takes effect before the 'block quick' rule right at the top... so besides allowing for cleaner rulesets, you could say it's a security fix too. I am using new syntax for years now, and although there are a lot of improvements, there is also downside. I have /24 public network, where I need to have one catch all NAT rule, but also exceptions (smtp servers translate to other public IPs, vpn clients to their own public IPs etc). If I have a lot of subnets behind NAT firewall, I need to specify them all for catch all NAT rule, listing exceptions (this is of course shortened, actually I need to declare 100 or so networks and dozens of exceptions): table catchallnat { 10.20.69.0/24 10.43.26.0/22 \ !10.20.69.15 !10.43.26.29 } smtp = { 10.20.69.15 } vpn = { 10.43.26.29 } ... match out on $ext_if inet from catchallnat to any nat-to $catchallnat match out on $ext_if inet from $smtp to any nat-to $smtp-nat match out on $ext_if inet from $vpn to any nat-to $vpn-nat I don't know if there would be negative consequences for other pf aspects, but for me it would be better if more specific match rules overrided more general match rules. This way I would not have to maintain catchallnat table with list of subnets and exceptions. -- Marko Cupać
obsd pf
Hi folks. I am studying obsd pf and saw there are no more nat rules and rdr rules the old way. Now it is nat-to and rdr-to. What is the motivation for match rule ? Time ago, the last match for a filter rule was the winner, for the nat and rdr the first match is the winner. And now, what is it the policy ? Thanks once more. [] Fried
Re: obsd pf
On Mon, Mar 17, 2014 at 09:53:43PM -0300, Friedrich Locke wrote: Hi folks. I am studying obsd pf and saw there are no more nat rules and rdr rules the old way. Yes, this changed with OpenBSD 4.7, in 2010. The change is documented in the 4.7 Upgrade Guide: http://www.openbsd.org/faq/upgrade47.html This will help you understand how to migrate your older systems to 2010 and later implementations of PF. Now it is nat-to and rdr-to. What is the motivation for match rule ? This allows global options to be set. From pf.conf(5): match The packet is matched. This mechanism is used to provide fine grained filtering without altering the block/pass state of a packet. match rules differ from block and pass rules in that parameters are set every time a packet matches the rule, not only on the last matching rule. For the following parameters, this means that the parameter effectively becomes ``sticky'' until explicitly overridden: nat-to, binat-to, rdr-to, queue, rtable, and scrub.
Re: obsd pf
On 2014-03-18, Friedrich Locke friedrich.lo...@gmail.com wrote: Hi folks. I am studying obsd pf and saw there are no more nat rules and rdr rules the old way. old - note that this is something from nearly 5 years ago. See http://marc.info/?l=openbsd-miscm=125181847818600w=2 for a quick introduction. I'm sure it has been covered in some of Henning's presentations as well. Now it is nat-to and rdr-to. What is the motivation for match rule ? Time ago, the last match for a filter rule was the winner, for the nat and rdr the first match is the winner. And now, what is it the policy ? Thanks once more. [] Fried The policy is as document in pf.conf(5). The ruleset is now traversed in order, changes made in match rules are sticky and affect rules lower down in the ruleset. More predictable, no more oh this 'nat pass' rule which you included halfway down the ruleset actually takes effect before the 'block quick' rule right at the top... so besides allowing for cleaner rulesets, you could say it's a security fix too.
OBSD PF / Carp and pfsync issue
I setup a pair of OBSD box's with carp pfsync last week, They appeared to working when I left them although the number of states on each was out by about 20%. I had the leave them like they were, but when I checked on them this morning I noticed that the backup box only has about 15 states and the active box has about 8000! I compared the hostname.vlan .carp files on each box and realised that I has an extra character in one of the carp password fields in one of the files. I fixed this but haven't done a sh /etc/netstart yet as don't want to do that remotely. The wrong password in the files makes sense and will account for the missing 20% states but could the wrong password have been seen as a denial of service against pfsync and have caused it to stop syncing ? I've had a look at the /var/log/messages daemon files but there's nothing there. PF doesn't seem to be blocking anything and if I run tcpdump on the vlan's I can see carp broadcasts (I don't understand them, but they are there). Does anyone have any suggestions. Thanks Keith.
OBSD+PF+VLAN+CARP
Good Morning, I still seem to be having problems with PF+VLANs. It seems that PF does not want to NAT traffic from my internal VLAN to my external VLAN IP address. Can someone advise if they have managed to get PF (NAT) + VLAN + CARP working, and or if anyone has experienced the same issues as myself? Regards, Garron -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: OBSD+PF+VLAN+CARP
On 2007/06/04 15:16, [EMAIL PROTECTED] wrote: Can someone advise if they have managed to get PF (NAT) + VLAN + CARP working yes. if you want more help, give more information.
Re: OBSD+PF+VLAN+CARP
On Mon, 4 Jun 2007 15:16:47 +0100, [EMAIL PROTECTED] wrote: Good Morning, I still seem to be having problems with PF+VLANs. It seems that PF does not want to NAT traffic from my internal VLAN to my external VLAN IP address. Can someone advise if they have managed to get PF (NAT) + VLAN + CARP working, and or if anyone has experienced the same issues as myself? Of course it works, a cursory search of the archives would have told you that. Show us your pf.conf and hostname.* files. -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net