Re: pf best practices: in or out
Hi Ari, In most cases, block all and then perform conditional pass in on traffic. Depending on your requirements you would conclude your rules with explicit pass out or just a general pass out 'all' (the former in the newer syntax of PF allows you to control queues, operational tags etc - but that won't help you with the current implementation of PF in FreeBSD). DNAT isn't a thing in PF (I assume you were looking how you'd do it if you were coming from Linux). Incoming will manipulate where required when rdr etc. Only outbound needs NAT binding. Cheers, Jason. On 25 June 2018 at 14:12, Aristedes Maniatis wrote: > Hi all > > pf has rules that can operate either 'in' or 'out'. That is, on traffic > entering or leaving an interface. I'm trying to consolidate my rules to > make them easier to understand and update, so it seems a bit pointless to > have the same rules twice. > > Are there any best practices on whether it makes more sense to put rules > on the in or out side? I could bind all the rules to the internet facing > interface and then use "in" for inbound traffic and "out" for outbound. > Does that makes sense? Does it make any difference from a performance point > of view? > > Secondly, where do DNAT rules execute in the sequence? Do they change the > destination IP in between the in and out pass pf rules? > > > I'm not currently subscribed here, so please cc me on replies. > > Thanks > > Ari > > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- "If my calculations are correct, when this baby hits 88MPH, you're gonna to see some serious shit" - Emmett "Doc" Brown ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 11.2-RC3 regression - networking igb driver
On 06/24/18 18:30, Jim Pingle wrote: On 6/23/2018 1:27 PM, David Samms wrote: There is a regression in 11.2-RC3 that effects the igb driver for Intels C2000 SoC I354 Quad GbE Controller Supermicro A1SRi-2558F http://www.supermicro.com/products/motherboard/Atom/X10/A1SRi-2558F.cfm This server has run 10.x and 11.x fine up till 11.2-RC3. PROBLEM: with 11.2-RC3 the server boots and gets a network connection to the cable modem, but the interface (igb0) resets every 4-8 second. The reset time appears to be related to network load, but reset withing 10s with next to no traffic. I did try swapping cables, but with no effect. With each reset the interface successfully obtains an IP address via DHCP, works for a few seconds and resets. Restoring the server to 11.1-RELEASE-p10 resolves the problem. Any suggestions? Does your DHCP server send you an MTU, perhaps? Before the interface resets, what does its MTU show? You might try creating a dhclient.conf that sets "supersede interface-mtu 0;" and see if that helps. The MTU from DHCP feature is new (see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206721 ) and e1000 interfaces will reset when applying the MTU. Jim P. Jim, Thank you for your kind reply. I believe you have correctly identified my issue. My ISP is Charter and the modem is a Arris TM822. Running off a live CD of both 11.2-RC3 and 12-CURRENT, I can see that DHCP receives a MTU of 576. In https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206721 they mention that this is an invalid value, and running dhclient -d, I can see that dhclient considers the value invalid and does reset the interface and makes another request. Interestingly, the interface doesn't appear to actually reset until the new address is received. Manually setting the interface with ifconfig/route, I can ping 8.8.8.8 with MTU of 576, but I didn't try any data transfers. Using ifconfig to set MTU 1500 works fine too. All said, I think we have a rather poor DHCP client in 11.2 and a BREAKING change for many casual users. At the very least, dhclient should be complaining of invalid values being received, that would help the user recover quickly. As of now, all you see in the log is that the interface reset. Ideally dhclient would log the invalid MTU as an error but continue as it did in 11.1 with a valid MTU. Again, thank you for taking the time to help me figure out this puzzle. I am on holiday for the next 5 days and will not be on the internet so won't be able to reply for a while. -- David Samms ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
pf best practices: in or out
Hi all pf has rules that can operate either 'in' or 'out'. That is, on traffic entering or leaving an interface. I'm trying to consolidate my rules to make them easier to understand and update, so it seems a bit pointless to have the same rules twice. Are there any best practices on whether it makes more sense to put rules on the in or out side? I could bind all the rules to the internet facing interface and then use "in" for inbound traffic and "out" for outbound. Does that makes sense? Does it make any difference from a performance point of view? Secondly, where do DNAT rules execute in the sequence? Do they change the destination IP in between the in and out pass pf rules? I'm not currently subscribed here, so please cc me on replies. Thanks Ari ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 11.2-RC3 regression - networking igb driver
On 6/23/2018 1:27 PM, David Samms wrote: > There is a regression in 11.2-RC3 that effects the igb driver for Intels > C2000 SoC I354 Quad GbE Controller > > Supermicro A1SRi-2558F > http://www.supermicro.com/products/motherboard/Atom/X10/A1SRi-2558F.cfm > > This server has run 10.x and 11.x fine up till 11.2-RC3. > > PROBLEM: > with 11.2-RC3 the server boots and gets a network connection to the > cable modem, but the interface (igb0) resets every 4-8 second. The reset > time appears to be related to network load, but reset withing 10s with > next to no traffic. I did try swapping cables, but with no effect. With > each reset the interface successfully obtains an IP address via DHCP, > works for a few seconds and resets. > > Restoring the server to 11.1-RELEASE-p10 resolves the problem. > > Any suggestions? Does your DHCP server send you an MTU, perhaps? Before the interface resets, what does its MTU show? You might try creating a dhclient.conf that sets "supersede interface-mtu 0;" and see if that helps. The MTU from DHCP feature is new (see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206721 ) and e1000 interfaces will reset when applying the MTU. Jim P. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Problem reports for sta...@freebsd.org that need special attention
To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status |Bug Id | Description +---+--- Open|227213 | FreeBSD 10.4 kernel deadlocks on sysctlmemlock 1 problems total for which you should take action. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ATI video problem - slow desktop - 100% cpu load [semi-solved]
On 06/23/18 00:40, Mark Saad wrote: Vincent I used the scfb driver in openbsd land for a work project . Currently I am using 11-STABLE with the Radeon driver but at one point I had a different card under 11.0 that didn’t work unless I used the scfb driver . Hi! If you are using FreeBSD 11.2 or later (stable or current) you should be able to use graphics/drm-stable-kmod and get acceleration with your ATI video cards. Please try it out! Regards -- Niclas ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: jail related inconsistencies in FreeBSD tools parameters
James Gritton wrote on 2018/06/23 17:30: On 2018-06-22 16:03, Miroslav Lachman wrote: Chris H wrote on 2018/06/22 23:46: On Fri, 22 Jun 2018 23:13:17 +0200 "Miroslav Lachman" <000.f...@quip.cz> said I don't know if it is better to discuss it in jail@ or stable@ list so a do cross-post. FreeBSD has many jail aware utilities but they are inconsistent in taking JID as parameter. For example "sockstat" takes -j JID "Show only sockets belonging to the specified jail ID" and it means numeric ID only. On the other hand "ps" takes -J JID "This may be either the jid or name of the jail. Use -J 0 to display only host processes." The same apply for "top", it understands jid as a number or name of the jail too. Then again "cpuset" takes only numerical ID of the jail... Shouldn't it be consistent across all FreeBSD base utilities so all of them can use numerical ID and name? Good idea! Are you offering to create a patch? ;-) It'd be my guess that given they weren't all created at the same time, nor the same individual; that (quite probably?) the "jail" additions were also added at different times, and by different people. So I'd imagine that unless someone with a commit bit decides one day they'd like to take that on. Someone(tm) maybe you? will need to propose a patch. :-) If I can understand C sources I will create the patch by myself instead of just posting here. Unfortunately I am able to code in sh, php and a bit of javascript and perl but no C. :) Miroslav Lachman Sure, a PR would be handy for this - it's a pretty simple thing to add, and consistency would indeed be a good move. PR 229266 created https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229266 Kind regards Miroslav Lachman ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"