nat on addresses with different default routes

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

nat on addresses with different default routes

lausgans@gmail.com
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!

Reply | Threaded
Open this post in threaded view
|

Re: nat on addresses with different default routes

lausgans@gmail.com
I've added "quick" word to the probabilistic rules and it works better, but still not sure how to deal with vether.

  Исходное сообщение  
От: [hidden email]
Отправлено: среда, 8 июля 2015 г., 21:05
Кому: [hidden email]
Тема: 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!

Reply | Threaded
Open this post in threaded view
|

Re: nat on addresses with different default routes

Giancarlo Razzolini-3
In reply to this post by lausgans@gmail.com
Em 08-07-2015 15:05, [hidden email] 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

Reply | Threaded
Open this post in threaded view
|

Re: nat on addresses with different default routes

lausgans@gmail.com
> Giancarlo Razzolini <[hidden email]>:
>
> Em 08-07-2015 15:05, [hidden email] 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

Reply | Threaded
Open this post in threaded view
|

Re: nat on addresses with different default routes

Giancarlo Razzolini-3
Em 09-07-2015 02:27, [hidden email] 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

Reply | Threaded
Open this post in threaded view
|

Re: nat on addresses with different default routes

lausgans@gmail.com
> 9 июля 2015 г., в 17:14, Giancarlo Razzolini <[hidden email]> написал(а):
>
> Em 09-07-2015 02:27, [hidden email] 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.

Reply | Threaded
Open this post in threaded view
|

Re: nat on addresses with different default routes

Giancarlo Razzolini-3
Em 17-07-2015 14:17, [hidden email] 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

Reply | Threaded
Open this post in threaded view
|

Re: nat on addresses with different default routes

lausgans@gmail.com
> 17 июля 2015 г., в 22:35, Giancarlo Razzolini <[hidden email]> написал(а):
>
> Em 17-07-2015 14:17, [hidden email] 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.

Reply | Threaded
Open this post in threaded view
|

Re: nat on addresses with different default routes

Giancarlo Razzolini-3
Em 17-07-2015 17:38, [hidden email] 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

Reply | Threaded
Open this post in threaded view
|

Re: nat on addresses with different default routes

lausgans@gmail.com
> 18 июля 2015 г., в 1:34, Giancarlo Razzolini <[hidden email]> написал(а):
>
> Em 17-07-2015 17:38, [hidden email] 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