Skip site navigation (1)Skip section navigation (2) 
Date:      Sat, 28 Sep 2002 16:35:26 -0700
From:      Lars Eggert <larse@ISI.EDU>
To:        Ian Cartwright <ian351c@cox.net>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: VPN Routing through gif (4) tunnel
Message-ID:  <3D963CBE.4080803@isi.edu>
References:  <006001c26723$f80775f0$6600a8c0@iansxp>
next in thread | previous in thread | raw e-mail | index | archive | help 

[-- Attachment #1 --]
Ian,

Ian Cartwright wrote:
> 
> As I understand it, so long as the local tunnel endpoint is the external
> interface of the local gateway, the encapsulated traffic should already
> look like it is coming from the external interface and should not be
> NATed (while the traffic inside the tunnel looks like it is coming from
> my local RFC1918 network).

Yes, the tunnel should go between the external addresses. But your NAT 
is still causing a problem. Consider this packet, send from a host on 
your local network to a host behind the remote tunnel end:

	| 192.168.0.10->200.200.200.20 | Data |

When it reaches your local security gateway, there are two choices:

(1) NAT gets the packet first, in which case it will be translated into
| 100.100.100.1->200.200.200.20 | Data |

(2) IPsec gets the packet first, in which case it will be encapsulated 
(## is the IPsec header):
| 100.100.100.1->200.200.201.1 ## 192.168.0.10->200.200.200.20 | Data |

If the second case occurs, your current SA should already cause this 
to happen.	

> It is also my understanding that IPFILTER
> sees the traffic before the rest of the kernel (i.e. KAME) and may do
> the NATing before it enters the IPSec tunnel, thus munging the works
> entirely. This does not bode well.

That is your problem, I think. IPfilter goes first, and your current SA 
does not match the NAT'ed packet.

Try changing your SA so that the selector matches the packet under (1) 
above, so the final packet would look like
| 100.100.100.1->200.200.201.1 ## 100.100.100.1->200.200.200.20 | Data |

This is moderately ugly, since we're using the same address in the inner 
and outer header, but that's what you get for using NATs... Note that 
there's a good chance that the IPsec implementation on either side will 
balk at this.

> Was my original assumption correct, that as long as the tunnel is
> specified correctly in the SPD, that the routing will happen
> automgically?

Yes. Once the correct SA is in place, forwarding over the tunnel should 
happen.

Lars
-- 
Lars Eggert <larse@isi.edu>           USC Information Sciences Institute

[-- Attachment #2 --]
0	*H
010	+0	*H
	080fErtcvE.0
	*H
010	UZA10UWestern Cape10U	Cape Town10U
Thawte Consulting1(0&UCertification Services Division1$0"UThawte Personal Freemail CA1+0)	*H
	personal-freemail@thawte.com0
000830000000Z
040827235959Z010	UZA10UWestern Cape10U	Cape Town10
U
Thawte10UCertificate Services1(0&UPersonal Freemail RSA 2000.8.3000
	*H
032c	%E>nx'gڈD)c5*mp<ܮto034qmOe
KaU5u'rװ|CBPQ<9TIf-	kiN0L0)U"0 010UPrivateLabel1-2970U00U0
	*H
1KG]qSl]y=&b""I'{9$
*8PUl
LGlX1B	li+@]jy.%݊
Z<D&iHΥbb090%A0
	*H
010	UZA10UWestern Cape10U	Cape Town10
U
Thawte10UCertificate Services1(0&UPersonal Freemail RSA 2000.8.300
020824185339Z
030824185339Z0T10
UEggert1
0U*Lars10ULars Eggert10	*H
	
larse@isi.edu0"0
	*H
0
6Fxΰ7aED&0+Dj)ֽXCUcnleijmz~S0JjWV~	1^({IݛLjӖ
ao:bP}WLVܱ욗cDɖ_Kv.A(W49;Z8-uXE
6b
@_0%#d`Rto5 L0R`w@7
r	Hcc	U3%7N_oV0T0*+e!000L2uMyffBNUbNJJcdZ2s0U0
larse@isi.edu0U00
	*H
]Ȕ,fK<cjRZeLan@Z6,=
fK?yO#8+	Ni*LSfpQg<(aӒ$kTx_AL1>ގ|S090%A0
	*H
010	UZA10UWestern Cape10U	Cape Town10
U
Thawte10UCertificate Services1(0&UPersonal Freemail RSA 2000.8.300
020824185339Z
030824185339Z0T10
UEggert1
0U*Lars10ULars Eggert10	*H
	
larse@isi.edu0"0
	*H
0
6Fxΰ7aED&0+Dj)ֽXCUcnleijmz~S0JjWV~	1^({IݛLjӖ
ao:bP}WLVܱ욗cDɖ_Kv.A(W49;Z8-uXE
6b
@_0%#d`Rto5 L0R`w@7
r	Hcc	U3%7N_oV0T0*+e!000L2uMyffBNUbNJJcdZ2s0U0
larse@isi.edu0U00
	*H
]Ȕ,fK<cjRZeLan@Z6,=
fK?yO#8+	Ni*LSfpQg<(aӒ$kTx_AL1>ގ|S1'0#0010	UZA10UWestern Cape10U	Cape Town10
U
Thawte10UCertificate Services1(0&UPersonal Freemail RSA 2000.8.30%A0	+a0	*H
	1	*H
0	*H
	1
020928233526Z0#	*H
	1o44Z+46NFg0R	*H
	1E0C0
*H
0*H
0
*H
@0+0
*H
(0*H
	1010	UZA10UWestern Cape10U	Cape Town10
U
Thawte10UCertificate Services1(0&UPersonal Freemail RSA 2000.8.30%A0
	*H
3`JC,捳E1wQ4-ЪkARziă=}/BmzqZՁJUJpps|<,4Ge0nLJF*I,'P,`oH<b'\M|HS9./@&ncTlX<,0(Q2ÈLȓ3cS"۟JCl2<qCD.:DuƦHB+

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D963CBE.4080803>