On Wed, 31 Aug 2016 16:09:30 +0200
Reyk Floeter <[email protected]> wrote:

> On Wed, Aug 31, 2016 at 03:26:53PM +0200, Vincent Gross wrote:
> > On Thu, 11 Aug 2016 16:57:27 +0100
> > Stuart Henderson <[email protected]> wrote:
> >   
> > > On 2016/06/27 13:00, J?r?mie Courr?ges-Anglas wrote:  
> > [...]    
> > > > 
> > > > I also gave my ok to vgross by IM.
> > > > 
> > > > I know that some concerns have been exposed privately, I was not
> > > > Cc'd, thus I have no idea what is the current status of that
> > > > discussion.  To the people concerned, please keep me / us
> > > > updated about that discussion and Cc us.    
> > > 
> > > How are things looking with IN_SENDSRCADDR now, are there any
> > > remaining concerns that need fixing before it could be committed?
> > > (Also if anyone has a share-able diff to use this with iked it
> > > would be quite handy..)
> > >   
> > 
> > Tested locally with two iked on two distinct rdomains plus a bit of
> > LD_PRELOAD goop. Unfortunately I couldn't ping from one rdom to the
> > other, but I also have this problem without my patch, so I am
> > confident this ping problem is unrelated.
> > 
> > I would be very grateful if someone could test this.
> >   
> 
> I don't know why you need LD_PRELOAD.
> 

I wanted to use different key sets for each iked instance.

> When testing iked with two different rdomains, you have to create an
> enc(4) device per rdomain, or no ipsec traffic will flow.  enc0 is for
> rdomain 0 only.
> 
> # ifconfig enc1 rdomain up
> # ifconfig enc2 rdomain up
> # route -T 1 exec iked -ddvvf /etc/iked.conf.1
> # route -T 2 exec iked -ddvvf /etc/iked.conf.2

Well, look at what you did, I understood why my pings wouldn't
go through !

Hm, turns out I can send esp'ed data, when using the not-default
address, but I can't receive yet.

This is my test bench :

---------- A side:

$ doas ifconfig pair10 rdomain 10 10.124.0.10/24 up
$ doas ifconfig enc10 rdomain 10 up
$ doas ifconfig vether10 rdomain 10 10.123.10.1/24 up
$ doas route -T 10 add 10.123.11.0/24 10.124.0.11
$ cat iked.a.conf
ikev2 active esp from 10.123.10.0/24 to 10.124.0.11 \
  local 10.123.10.1 peer 10.124.0.11 \
  srcid a.test dstid b.test


"route -T 10 exec ipsecctl -s all" output :
FLOWS:
flow esp in from 10.124.0.11 to 10.123.10.0/24 peer 10.124.0.11 srcid 
FQDN/a.test dstid FQDN/b.test type use
flow esp out from 10.123.10.0/24 to 10.124.0.11 peer 10.124.0.11 srcid 
FQDN/a.test dstid FQDN/b.test type require
flow esp out from ::/0 to ::/0 type deny

SAD:
esp tunnel from 10.124.0.11 to 10.124.0.10 spi 0x2ebe4b1b auth hmac-sha2-256 
enc aes-256
esp tunnel from 10.124.0.10 to 10.124.0.11 spi 0x3c4b29c3 auth hmac-sha2-256 
enc aes-256



---------- B side:

$ doas ifconfig pair11 rdomain 11 10.124.0.11/24 up
$ doas ifconfig enc11 rdomain 11 up
$ doas ifconfig vether11 rdomain 11 10.123.11.1/24 up
$ doas route -T 11 add 10.123.10.0/24 10.124.0.10
$ cat iked.b.conf
ikev2 active esp from 10.124.0.11 to 10.123.10.0/24 \
  local 10.124.0.11 peer 10.123.10.1 \
  srcid b.test dstid a.test


"route -T 11 exec ipsecctl -s all" output :
FLOWS:
flow esp in from 10.123.10.0/24 to 10.124.0.11 peer 10.124.0.10 srcid 
FQDN/b.test dstid FQDN/a.test type use
flow esp out from 10.124.0.11 to 10.123.10.0/24 peer 10.124.0.10 srcid 
FQDN/b.test dstid FQDN/a.test type require
flow esp out from ::/0 to ::/0 type deny

SAD:
esp tunnel from 10.124.0.11 to 10.124.0.10 spi 0x2ebe4b1b auth hmac-sha2-256 
enc aes-256
esp tunnel from 10.124.0.10 to 10.124.0.11 spi 0x3c4b29c3 auth hmac-sha2-256 
enc aes-256



---------- The fun part:

run "tcpdump -ni pair10", then "route -T 10 exec ping -I 10.123.10.1 
10.124.0.11" :

...
17:26:24.185391 esp 10.124.0.10 > 10.124.0.11 spi 0x3c4b29c3 seq 36 len 136
17:26:24.185797 10.124.0.11.4500 > 10.124.0.10.4500:udpencap: esp 10.124.0.11 > 
10.124.0.10 spi 0x2ebe4b1b seq 36 len 136
17:26:25.190350 esp 10.124.0.10 > 10.124.0.11 spi 0x3c4b29c3 seq 37 len 136
17:26:25.190680 10.124.0.11.4500 > 10.124.0.10.4500:udpencap: esp 10.124.0.11 > 
10.124.0.10 spi 0x2ebe4b1b seq 37 len 136
17:26:26.190344 esp 10.124.0.10 > 10.124.0.11 spi 0x3c4b29c3 seq 38 len 136
17:26:26.190701 10.124.0.11.4500 > 10.124.0.10.4500:udpencap: esp 10.124.0.11 > 
10.124.0.10 spi 0x2ebe4b1b seq 38 len 136
...


The udpencap'd return traffic is not picked up by enc10, so your ping replies 
are lost ...

Reply via email to