[Openswan Users] VPN connection to server behind firewall

[Paul Wouters]

On Wed, 9 Nov 2005, Albert Strasheim wrote:

> behind a firewall. I am using Openswan 2.4.2dr5 and l2tpd 0.69-13 on
> Fedora Core 4 with the 2.6.13-1.1532_FC4 kernel. VPN connections on my
> internal LAN to the VPN server work fine. However, I am having problems
> with connections that traverse the firewall.
>
> The firewall has a public IP address (a.b.c.d) and a private IP address
> 10.2.2.251. The VPN server has private IP address 10.2.0.13.
>
> I have set up 2 firewall rules using Shorewall on the firewall.
> Shorewall is a frontend to iptables:
>
> DNAT     sdsl           loc:10.2.0.13   udp     500
> DNAT     sdsl           loc:10.2.0.13   udp     4500

does the firewall also probably NAT the packets from the VPN server back to
the internet?

> I have a few questions at this point. Should the firewall also forward
> protocols 50 and 51, or are all those packets encapsulated inside UDP
> packets going to port 4500?

Since your VPN server is behind NAT, all communication will go through udp
port 4500 after the initial udp port 500, so it should not be needed.

> Also, does my road warrior have to be able
> to accept connections on port 500 and/or 4500? Should the firewall be
> doing something else to the packets before forwarding them?

'connections' is a weird term in this case, since we're talking about UDP
which is 'connectionless'. Yes, the roadwarrior needs to be able to receive
udp (4)500 packets.

> On the road warrior, I imported the PKCS12 certificate and set up the
> connection using the New Connection Wizard. I tried all the possible
> values (0, 1, 2) for the AssumeUDPEncapsulationContextOnSendRule DWORD
> in HKLM\System\CurrentControlSet\Services\IPSec, to no avail. The road
> warrior has public IP address x.y.z.w.
>
> My Openswan configuration is as follows:
>
> config setup
>   virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16
>   nat_traversal=yes
> conn %default
>   keyingtries=1
>   compress=yes
>   disablearrivalcheck=no
>   authby=rsasig
>   leftrsasigkey=%cert
>   rightrsasigkey=%cert
> include /etc/ipsec.d/examples/no_oe.conf

> conn roadwarrior-l2tp
>   leftprotoport=17/0
>   rightprotoport=17/1701
>   also=roadwarrior
> conn roadwarrior-l2tp-updatedwin
>   leftprotoport=17/1701
>   rightprotoport=17/1701
>   also=roadwarrior

I would use one conn with 17/%any

> conn roadwarrior
>   left=%defaultroute
>   leftcert=vpnhost.mydomain.com.pem
>   right=%any
>   rightsubnet=vhost:%no,%priv
>   auto=add
>   pfs=no
>   compress=no

you prob also want rekey=no (only the client should rekey)

> The following appears in /var/log/secure when I inititate the connection
> from the road warrior:

> Nov  9 14:02:48 vpnhost pluto[4850]: "roadwarrior-l2tp"[4] x.y.z.w #2: cannot respond to IPsec SA request because no connection is known for a.b.c.d/32===10.2.0.13[<snip>, CN=vpnhost.mydomain.com]:17/1701...x.y.z.w[<snip>, CN=roadwarrior.mydomain.com]:17/1701

There might be a certificate problem. It also seems like there might be an
issue with the two roadwarriros connections since this is a connection from and
to port 1701, which in your conf should be roadwarrior-l2tp-updatedwin. This
might be because pluto didnt get as far as to switch the connname, but it could
also be one of our roadwarrior conns didnt load properly, and it is picking
the one with 17/0 since it is the only loaded conn.

Like I said, merge the two or drop support for unpatched Windows clients.

Paul