Re: nat on addresses with different default routes
18 июля 2015 г., в 1:34, Giancarlo Razzolini grazzol...@gmail.com написал(а): Em 17-07-2015 17:38, lausg...@gmail.com escreveu: Thanks much for all your good help! I will try it. No problem. For now I'm just still using probabilistic rules with quick keyword + fallback rule but using mpath instead of rdomain and this works smoothly now! Posting for reference. I don't know why I just haven't thought of it at first time, but my task is solveable easily by adding an anchor from dhclient-script like echo pass in on lan route-to { (cnmac1 `pfctl -t gw_cnmac1 -T show`), (cnmac2 `pfctl -t gw_cnmac2 -T show`) } least-states | pfctl -a balancing -f - If I recall correctly, you could mix mpath with rdomains. But, as much as I like rdomains, I still prefer mpath for multiple ISP's setups. If I'll need to setup multi-isp setup ever, I'll use anchors and make ifstated check for the gateways availability, and update the rules accordingly like you suggested. ifstated works great in this. It's a state machine, so you can code any scripts into it and handle very complex setups. The most complex I ever recall I've done was a firewall with 4 different ISP's, and a complex ruleset. There were all sorts of checks and failovers, lots of anchors. This was almost 10 years ago. Things have changed. But some didn't. Cheers, Giancarlo Razzolini
Re: nat on addresses with different default routes
9 июля 2015 г., в 17:14, Giancarlo Razzolini grazzol...@gmail.com написал(а): Em 09-07-2015 02:27, lausg...@gmail.com escreveu: Thank you for the answer! Indeed its a more correct approach. Is there a simple way to teach (any openbsd compliant) dhcp client to use mpath? Also not sure whether it will work in this case:http://www.rinta-aho.org/blog/?p=214 I don't recall if the openbsd base dhclient have it, but you could possibly use some that is on ports and make it not add the default routes. And, you could make it call a script that creates them. They need to be created with the -mpath modifier anyway. Cheers, Giancarlo Razzolini Ok, so isc-dhclient + dhclient-script with this modification http://www.rinta-aho.org/docs/openbsd-pf/dhclient-script.patch supplied to it + route-to rules used like in http://www.rinta-aho.org/docs/openbsd-pf/pf.conf do work. However round-robin http://www.openbsd.org/faq/pf/pools.html#outgoing construction doesn't work for this case. Rule like pass in on lan inet from lan:network to !lan:0 route-to { (cnmac1 gw_cnmac1), (cnmac2 gw_cnmac2) } round-robin fails with multiple tables or dynamic interfaces not supported for translation or routing and I don't know other way of dynamic passing of gateways from dhclient to pf for this rule without usage of multiple tables.
Re: nat on addresses with different default routes
17 июля 2015 г., в 22:35, Giancarlo Razzolini grazzol...@gmail.com написал(а): Em 17-07-2015 14:17, lausg...@gmail.com escreveu: Ok, so isc-dhclient + dhclient-script with this modificationhttp://www.rinta-aho.org/docs/openbsd-pf/dhclient-script.patch supplied to it + route-to rules used like inhttp://www.rinta-aho.org/docs/openbsd-pf/pf.conf do work. Nice to hear that. This script can sure be improved. However round-robinhttp://www.openbsd.org/faq/pf/pools.html#outgoing construction doesn't work for this case. Rule like pass in on lan inet from lan:network to !lan:0 route-to { (cnmac1 gw_cnmac1), (cnmac2 gw_cnmac2) } round-robin fails with multiple tables or dynamic interfaces not supported for translation or routing and I don't know other way of dynamic passing of gateways from dhclient to pf for this rule without usage of multiple tables. As I mentioned, I would use least-states, instead of round-robin. Also, I had a similar issue and solved it using (egress). Since your interfaces will have default routes, they will be all part of the egress group. You can exploit that. Use tags and tcpdump to debug your rules, I believe you can find a solution. Cheers, Giancarlo Razzolini Thanks much for all your good help! I will try it. For now I'm just still using probabilistic rules with quick keyword + fallback rule but using mpath instead of rdomain and this works smoothly now! If I'll need to setup multi-isp setup ever, I'll use anchors and make ifstated check for the gateways availability, and update the rules accordingly like you suggested.
nat on addresses with different default routes
My isp gives me a bunch of dynamic external ip addresses via dhcp one per nic. They don't share common default gateway route all together, so I'm forced to put each next in its own rdomain. As so, http://www.openbsd.org/faq/pf/pools.html#nat or http://www.openbsd.org/faq/pf/pools.html#outgoing examples are not applicable. I'm just interested in random redistribution. Here's an ugly solution I currently use: match out on em0 inet from lan:network nat-to (em0:0) match out on em1 inet from lan:network nat-to (em1:0) match out on em2 inet from lan:network nat-to (em2:0) pass in on lan inet from lan:network to !lan:0 # fallback pass in on lan inet from lan:network to !lan:0 rtable 1 probability 34% pass in on lan inet from lan:network to !lan:0 rtable 2 probability 34% What would be the correct way of doing this? Is it possible to achieve this using vether(4) without big performance penalty (which occurs when real nic and virtual interface which relies on it are not in the same rdomain)? Thanks!
Re: nat on addresses with different default routes
I've added quick word to the probabilistic rules and it works better, but still not sure how to deal with vether. Исходное сообщение От: lausg...@gmail.com Отправлено: среда, 8 июля 2015 г., 21:05 Кому: misc@openbsd.org Тема: nat on addresses with different default routes My isp gives me a bunch of dynamic external ip addresses via dhcp one per nic. They don't share common default gateway route all together, so I'm forced to put each next in its own rdomain. As so, http://www.openbsd.org/faq/pf/pools.html#nat or http://www.openbsd.org/faq/pf/pools.html#outgoing examples are not applicable. I'm just interested in random redistribution. Here's an ugly solution I currently use: match out on em0 inet from lan:network nat-to (em0:0) match out on em1 inet from lan:network nat-to (em1:0) match out on em2 inet from lan:network nat-to (em2:0) pass in on lan inet from lan:network to !lan:0 # fallback pass in on lan inet from lan:network to !lan:0 rtable 1 probability 34% pass in on lan inet from lan:network to !lan:0 rtable 2 probability 34% What would be the correct way of doing this? Is it possible to achieve this using vether(4) without big performance penalty (which occurs when real nic and virtual interface which relies on it are not in the same rdomain)? Thanks!
Re: nat on addresses with different default routes
Giancarlo Razzolini grazzol...@gmail.com: Em 08-07-2015 15:05, lausg...@gmail.com escreveu: My isp gives me a bunch of dynamic external ip addresses via dhcp one per nic. They don't share common default gateway route all together, so I'm forced to put each next in its own rdomain. As so, http://www.openbsd.org/faq/pf/pools.html#nat or http://www.openbsd.org/faq/pf/pools.html#outgoing examples are not applicable. I'm just interested in random redistribution. Here's an ugly solution I currently use: match out on em0 inet from lan:network nat-to (em0:0) match out on em1 inet from lan:network nat-to (em1:0) match out on em2 inet from lan:network nat-to (em2:0) pass in on lan inet from lan:network to !lan:0 # fallback pass in on lan inet from lan:network to !lan:0 rtable 1 probability 34% pass in on lan inet from lan:network to !lan:0 rtable 2 probability 34% What would be the correct way of doing this? Is it possible to achieve this using vether(4) without big performance penalty (which occurs when real nic and virtual interface which relies on it are not in the same rdomain)? Thanks! You could, instead of using routing domains, enable mpath, and then deal with the default gateways using route-to and reply-to. Load balancing can be achieved with the round-robin or, even better, least-states directive. To put a cherry on top, you can make all these rules on anchors and make ifstated check for the gateways availability, and update the rules accordingly. At least this is my approach for dealing with many default gateways. Using tags you can write an even conciser ruleset. Cheers, Giancarlo Razzolini Thank you for the answer! Indeed its a more correct approach. Is there a simple way to teach (any openbsd compliant) dhcp client to use mpath? Also not sure whether it will work in this case: http://www.rinta-aho.org/blog/?p=214
Re: NetBSD has now support for USB on EdgeRouter Lite
Bruno Bigras-2 wrote: 2015-06-18 2:00 GMT-04:00 lausgans: Ah, just still not compiled in: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/octeon/conf/GENERIC.diff? r1=1.17r2=1.18f=h I'm looking forward for this. Is it ready to be tested or should I wait? Could you guys please add usb* at dwctwo? to the snapshots kernels for octeon? So we could actually use it or at least test. Thanks.
Re: NetBSD has now support for USB on EdgeRouter Lite
lausgans lausgans at gmail.com writes: Doesn't work on mine: dwctwo at iobus0 base 0x118006800 irq 56 not configured ... Available disks are: none. Tried all kind of bsd from here http://ftp.openbsd.org/pub/OpenBSD/5.7/octeon/ also both all kind of bsd as well as bsd.rd extracted from miniroot57.fs from here http://ftp.openbsd.org/pub/OpenBSD/snapshots/octeon/ Ah, just still not compiled in: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/octeon/conf/GENERIC.diff? r1=1.17r2=1.18f=h
Re: NetBSD has now support for USB on EdgeRouter Lite
Jonathan Gray jsg at jsg.id.au writes: On Wed, Jun 17, 2015 at 12:25:54PM +0300, lausgans at gmail.com wrote: Just a heads up. Anyone to merge this into OpenBSD? http://mail-index.netbsd.org/source-changes/2015/05/01/msg065510.html [ https://blog.netbsd.org/tnf/entry/hands_on_experience_with_edgerouter ] Thanks. http://marc.info/?l=openbsd-cvsm=143005106108571w=2 http://marc.info/?l=openbsd-cvsm=143387765930344w=2 Doesn't work on mine: dwctwo at iobus0 base 0x118006800 irq 56 not configured ... Available disks are: none. Tried all kind of bsd from here http://ftp.openbsd.org/pub/OpenBSD/5.7/octeon/ also both all kind of bsd as well as bsd.rd extracted from miniroot57.fs from here http://ftp.openbsd.org/pub/OpenBSD/snapshots/octeon/
NetBSD has now support for USB on EdgeRouter Lite
Just a heads up. Anyone to merge this into OpenBSD? http://mail-index.netbsd.org/source-changes/2015/05/01/msg065510.html [ https://blog.netbsd.org/tnf/entry/hands_on_experience_with_edgerouter ] Thanks.