Question about xfrm by MARK feature

Question about xfrm by MARK feature

[Gerd v. Egidy]

Hi Jamal,

while looking through the 2.6.34 changelog I found the xfrm by MARK feature 
you developed in february. I'm currently working on NAT for ipsec connections 
and thought your feature might help me.

For example I have 2 different remote networks with the same ip network each 
and both of them have a tunnel to the same local network. I map their IPs to 
something different so I can distinguish them in the local network. But after 
the nat the xfrm code sees two tunnels with exactly the same values. So this 
can't work.

But if I understood your feature correctly, I can now mark the packets (e.g. 
in iptables with ... -j MARK --set-mark 1) and have xfrm select the correct 
ipsec tunnel via the mark. Correct?

But does your feature also set the mark on packets decrypted by xfrm? I need 
some way to find out from which tunnel the packet came to correctly treat it. 

Do you know if any of the ipsec solutions for linux (e.g. strongswan, 
openswan, racoon) already have support for this feature or are developing on 
it?

Kind regards,

Gerd

-- 
Address (better: trap) for people I really don't want to get mail from:
jonas@cactusamerica.com

Re: Question about xfrm by MARK feature

[Patrick McHardy]

Gerd v. Egidy wrote:
> Hi Jamal,
>
> while looking through the 2.6.34 changelog I found the xfrm by MARK feature 
> you developed in february. I'm currently working on NAT for ipsec connections 
> and thought your feature might help me.
>
> For example I have 2 different remote networks with the same ip network each 
> and both of them have a tunnel to the same local network. I map their IPs to 
> something different so I can distinguish them in the local network. But after 
> the nat the xfrm code sees two tunnels with exactly the same values. So this 
> can't work.
>
> But if I understood your feature correctly, I can now mark the packets (e.g. 
> in iptables with ... -j MARK --set-mark 1) and have xfrm select the correct 
> ipsec tunnel via the mark. Correct?
>
> But does your feature also set the mark on packets decrypted by xfrm? I need 
> some way to find out from which tunnel the packet came to correctly treat it. 
>   

You should be able to use the policy match to distinguish the tunnels,
f.i. by matching on the tunnel endpoints.

Re: Question about xfrm by MARK feature

[Gerd v. Egidy]

> > But does your feature also set the mark on packets decrypted by xfrm? I
> > need some way to find out from which tunnel the packet came to correctly
> > treat it.
> 
> You should be able to use the policy match to distinguish the tunnels,
> f.i. by matching on the tunnel endpoints.

That would work for endpoints with fixed ips. But as soon as the endpoint has a 
dynamic ip, I'd have to change the iptables depending on the vpns currently 
connected. This is something I want to avoid in any case. 

Reason is that I'd have to introduce some kind of locking around the calls to 
iptables. Otherwise two connections established or disconnected nearly 
simultaneously could result in loss of the rules for one of them.

Kind regards,

Gerd

Re: Question about xfrm by MARK feature

[Herbert Xu]

On Thu, Jun 24, 2010 at 12:13:57AM +0200, Gerd v. Egidy wrote:
> 
> That would work for endpoints with fixed ips. But as soon as the endpoint has a 
> dynamic ip, I'd have to change the iptables depending on the vpns currently 
> connected. This is something I want to avoid in any case. 

That's what reqids are for.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Question about xfrm by MARK feature

[jamal]

Hi Gerd,

On Wed, 2010-06-23 at 18:03 +0200, Gerd v. Egidy wrote:
> Hi Jamal,
> 
> while looking through the 2.6.34 changelog I found the xfrm by MARK feature 
> you developed in february. I'm currently working on NAT for ipsec connections 
> and thought your feature might help me.
> 
> For example I have 2 different remote networks with the same ip network each 
> and both of them have a tunnel to the same local network. 

It seems "Same IP network" means that two remote locations will have
exactly same IP address? This is hard of course - but nat may do it..
There's also the nat zones feature that Patrick introduced a while back
that may help you

> I map their IPs to 
> something different so I can distinguish them in the local network. But after 
> the nat the xfrm code sees two tunnels with exactly the same values. So this 
> can't work.
> 

Can you look at the incoming encrypted packet headers and tell if they
are from different remotes? If not, are different remotes coming in via
a different network device? If yes, you can install a tc rule to mark
them as they come in before decryption and that mark should stay with
them even after they get decrypted.

> But if I understood your feature correctly, I can now mark the packets (e.g. 
> in iptables with ... -j MARK --set-mark 1) and have xfrm select the correct 
> ipsec tunnel via the mark. Correct?
> 
> But does your feature also set the mark on packets decrypted by xfrm? I need 
> some way to find out from which tunnel the packet came to correctly treat it. 
> 

Refer to above and also to policy routing.

> Do you know if any of the ipsec solutions for linux (e.g. strongswan, 
> openswan, racoon) already have support for this feature or are developing on 
> it?

AFAIK, only iproute2 can use marks. I believe the ike daemons can be
made to use reqid (as Herbert mentioned) but i am not sure that is 
sufficient for what you want.

cheers,
jamal

Re: Question about xfrm by MARK feature

[Gerd v. Egidy]

Hi Jamal,

thanks for your detailed answer.

> > For example I have 2 different remote networks with the same ip network
> > each and both of them have a tunnel to the same local network.
> 
> It seems "Same IP network" means that two remote locations will have
> exactly same IP address?

yes

> This is hard of course - but nat may do it..
> There's also the nat zones feature that Patrick introduced a while back
> that may help you

I'm using Patricks conntrack zones. And Patrick helped me with a input chain 
in the nat table. The other cases with e.g. a ip clash between local and 
remote net already work.

So only the case with two remotes and same ips is missing.

> > I map their IPs to
> > something different so I can distinguish them in the local network. But
> > after the nat the xfrm code sees two tunnels with exactly the same
> > values. So this can't work.
> 
> Can you look at the incoming encrypted packet headers and tell if they
> are from different remotes? If not, are different remotes coming in via
> a different network device? If yes, you can install a tc rule to mark
> them as they come in before decryption 

I planned to avoid looking at the remote gateway ip (to even allow two 
different remote gateways hiding natted behind the same ip) but that would be 
a good fallback solution if my other ideas don't work out.

> and that mark should stay with
> them even after they get decrypted.

Didn't know that, very good.

I just contacted the strongswan maintainers about reqids and marks. Let's see 
if this works out...

Kind regards,

Gerd

-- 
Address (better: trap) for people I really don't want to get mail from:
jonas@cactusamerica.com

Re: Question about xfrm by MARK feature

[jamal]

Hi Gerd,

On Fri, 2010-06-25 at 09:35 +0200, Gerd v. Egidy wrote:

> I planned to avoid looking at the remote gateway ip (to even allow two 
> different remote gateways hiding natted behind the same ip) but that would be 
> a good fallback solution if my other ideas don't work out.
> 

Doesnt have to be a remote IP...
If you can somehow even map a remote to some MAC address or incoming
virtual interface (such as a VLAN) that would do it as well.
Alternatively, you should probably look at namespaces  - i just find it
more usable when you have overlapping/conflicting ip addresses. You
of course will have to run strongswan per namespace if you dont want to
hack strongswan.

cheers,
jamal