-----BEGIN PGP SIGNED MESSAGE-----
On Tuesday 12 August 2003 10:26, Sven Schuster wrote:
> (x = 192.169)
>
> FreeS/Wan Router doing FreeS/Wan
> "Server" NAT to x.245.18 "Client"
> x.245.23 ----- x.245.18 x.201.18 ----- x.201.81
>
> All three boxes are Linux 2.4.x. When I'm disabling NAT on the router
> I can establish an ESP tunnel from x.201.81 without any problems. But
> when I enable NAT on the router box with
>
> iptables -t nat -A POSTROUTING -s 192.169.201.0/24 -d 192.169.245.0/24 \
> -o eth1 -j SNAT --to-source 192.169.245.18
*snip*
> Aug 12 15:54:12 vpn1 pluto[8676]: "samplehth"[2] 192.169.245.18:4500 #1:
> cannot
> respond to IPsec SA request because no connection is known for
> 192.169.245.23:4500...192.169.245.18:4500[192.169.201.81]===192.169.201.81/
As the above log excerpt indicates, your peer sees an attemptto negotiate a
tunnel with the following semantics: a security gateway address of
192.168.245.18 (the NAT'ted IP address) is negotating a tunnel which will
allow allow secure communications from 192.168.245.23 to 192.168.201.81.
This is common; when negotiating tunnels through NAT, the negotiation appears
to be coming from the NAT'ted IP address, and it's on behalf of the (usually
private) IP address of the actual negotiator. As NAT changes the apparent
source IP addresses involved in the negotiation, you need to update the
connection definition on 201.81 to match the following:
conn samplehth
left=192.169.245.18
leftsubnet=192.169.245.23/32
right=192.169.201.81
rightnexthop=192.169.201.18
esp=3des
pfs=yes
auto=start
(Though they don't seem appropriate to your situation, other options are to
use "rightsubnetwithin", detailed in the x.509 Installation and Configuration
guide, and "virtual_private/vhost", detailed in the NAT-T documentation.)
http://www.strongsec.com/freeswan/install.htm#section_4.4
http://open-source.arkoon.net/freeswan/README.NAT-Traversal.0.6
> The only differences on the "server" side are that
> "right" is set to "%any", rightnexthop is not set, and
> "auto" is set to "add".
> On the server side, I have this entry in ipsec.secrets:
>
> 192.169.245.23 %any: PSK "testing"
You can only use a single PSK for all your roadwarriors; using PSKs in that
situation inherently less secure than using RSA keys, so any time you can use
RSA signatures for authentication, I'd recommend you do so.
(As a aside, %any in the ipsec.secrets syntax means "if my peer's ID is any IP
address"; this it will bork if IDs become involved, even if by accident. The
man page for ipsec.secrets has more info on the syntax.
: PSK "testing"
... would mean, "anyone who wants to negotiate using a PSK with me uses this
secret".)
- --
Sam Sgro
[EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
Comment: For the matching public key, finger the Reply-To: address.
iQCVAwUBPzkgSkOSC4btEQUtAQFXQAQAifiAXiYUWkgafUpqGkmp6EVoAxluj6RN
fTU14ZsxcNYj41lFj+piRK5JRus9TVIENuxmRMLzNOUzgHfyFXcl3aKtwKZZldh8
7PDM3hGF4s/4yosi7rUSfxapi2jQVC2TeyNe6+RTgJ/dFcPbqkVVYtiDGkqEvuOO
yJy9avI+xRo=
=Ly6S
-----END PGP SIGNATURE-----
_______________________________________________
FreeS/WAN Users mailing list
[EMAIL PROTECTED]
https://mj2.freeswan.org/cgi-bin/mj_wwwusr
