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

[Patrick McHardy]

Post by 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.

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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Gerd v. Egidy]

Post by Patrick McHardy

Post by 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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Herbert Xu]

Post by Gerd v. Egidy
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,

[jamal]

Hi Gerd,

Post by 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.

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

Post by Gerd v. Egidy
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.

Post by Gerd v. Egidy
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.

Post by Gerd v. Egidy
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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Gerd v. Egidy]

Hi Jamal,

thanks for your detailed answer.

Post by jamal

Post by Gerd v. Egidy
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

Post by jamal
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.

Post by jamal

Post by Gerd v. Egidy
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.

Post by jamal
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

[jamal]

Hi Gerd,

Post by Gerd v. Egidy
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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html