[Openswan Users] Ipsec/l2tp server behind nat, again(2)

[Brad Johnson]

If incoming packets to OpenSwan are being DNAT''ed (port forwarded) by 
the NAT device, how could OpenSwan possibly realize it is being 
contacted via 12.34.112.177?
I think you may need to add a leftid to your server config, like this maybe:

leftid=12.34.112.177

Just an idea.

...Brad


Lux wrote:
> Hi all
>
> Sorry for opening a third thread on the same issue, but I'm still unable to
> get a working l2tp/ipsec server behind nat, and I begin to wonder if anyone
> has got it working with Openswan 2.6.x.
>
> I just upgraded to Openswan 2.6.18 and switched from PSK to certificate
> authentication, with no results.
>
> My setup is this:
>
> Openswan/xl2tpd server
> Real IP address 
> 192.168.0.100
>   |
>   |
> 192.168.0.254
>  NAT router
> 12.34.112.177
>   |
>   |
> .....
> Internet
> .....
>   |
>   |
> Road warrior
> Client with 
> 192.168.1.100
>
> In simple words, the server with IP 192.168.0.100 is visible to the outside
> world through 12.34.112.177.
> When I try to connect, I find in the Openswan logs:
>
> | find_host_pair: comparing to 192.168.0.100:500 0.0.0.0:500 
> |   checking hostpair 192.168.0.100/32 -> 0.0.0.0/32 is found
> |    match_id a=C=IT, ST=RE, L=Reggio Emilia, O=Lux Servizi, CN=Lux,
> E=xxxxx at iotti.biz
> |             b=(none)
> |    results  matched
> |   trusted_ca called with a=C=IT, ST=RE, L=Reggio Emilia, O=Lux Servizi,
> CN=lux CA, E=xxxxx at iotti.biz b=C=IT, ST=RE, L=Reggio Emilia, O=Lux Servizi,
> CN=lux CA, E=xxxxx at iotti.biz
> |   fc_try trying roadwarrior-l2tp:12.34.112.177/32:17/1701 ->
> 192.168.1.100/32:17/1701(virt) vs roadwarrior-l2tp:192.168.0.100/32:17/1701
> -> 0.0.0.0/32:17/1701(virt)
> |    our client(192.168.0.100/32) not in our_net (12.34.112.177/32)
> ...
> "roadwarrior-l2tp"[2] 79.7.5.10 #1: cannot respond to IPsec SA request
> because no connection is known for
> 12.34.112.177/32===192.168.0.100<192.168.0.100>[+S=C]:17/1701...79.7.5.10[C=
> IT, ST=RE, L=Reggio Emilia, O=Lux Servizi, CN=Lux,
> E=xxxxx at iotti.biz,+S=C]:17/1701===192.168.1.100/32
>
> Looking at the line "our client(192.168.0.100/32) not in our_net
> (12.34.112.177/32)" it seems that Openswan is unable to realize that, due to
> nat translation, it is being contacted via the public IP address
> 12.34.112.177), and that this public IP is simply the IP that was reserved
> for Openswan itself.
>
> I tried with and without type=transport obtaining the same result.
>
> Any ideas to get this to work?
>
> My config :
>
> version 2.0
>
> config setup
>         plutodebug="parsing emitting lifecycle dns oppo control controlmore
> pfkey nattraversal x509"
>         dumpdir=/tmp
>         interfaces=%defaultroute
>         nat_traversal=yes
>  
> virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!192
> .168.0.0/24
>         protostack=netkey
>
> conn %default
>         keyingtries=1
>         compress=yes
>         disablearrivalcheck=no
>         authby=rsasig
>         leftrsasigkey=%cert
>         rightrsasigkey=%cert
>
> conn roadwarrior-l2tp
>         authby=rsasig
>         pfs=no
>         auto=add
>         rekey=no
>         ikelifetime=8h
>         keylife=1h
>         type=transport
>         left=192.168.0.100
>         leftnexthop=192.168.0.254
>         leftrsasigkey=%cert
>         leftcert=localhost.crt
>         leftprotoport=17/1701
>         right=%any
>         rightca=%same
>         rightrsasigkey=%cert
>         rightprotoport=17/1701
>         rightsubnet=vhost:%no,%priv
>
> _______________________________________________
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
> Building and Integrating Virtual Private Networks with Openswan: 
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>