All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Gerd v. Egidy" <lists@egidy.de>
To: hadi@cyberus.ca
Cc: timo.teras@iki.fi, kaber@trash.net, herbert@gondor.apana.org.au,
	netdev@vger.kernel.org
Subject: Re: Question about xfrm by MARK feature
Date: Fri, 25 Jun 2010 09:35:30 +0200	[thread overview]
Message-ID: <201006250935.30967.lists@egidy.de> (raw)
In-Reply-To: <1277381094.3455.92.camel@bigi>

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

  reply	other threads:[~2010-06-25  7:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-23 16:03 Question about xfrm by MARK feature Gerd v. Egidy
2010-06-23 16:15 ` Patrick McHardy
2010-06-23 22:13   ` Gerd v. Egidy
2010-06-23 22:16     ` Herbert Xu
2010-06-24 12:04 ` jamal
2010-06-25  7:35   ` Gerd v. Egidy [this message]
2010-06-25 12:43     ` jamal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201006250935.30967.lists@egidy.de \
    --to=lists@egidy.de \
    --cc=hadi@cyberus.ca \
    --cc=herbert@gondor.apana.org.au \
    --cc=kaber@trash.net \
    --cc=netdev@vger.kernel.org \
    --cc=timo.teras@iki.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.