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
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
Re: nat on addresses with different default routes
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! 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
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.
Re: nat on addresses with different default routes
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
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
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
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
