[Openswan Users] VPN connection to server behind firewall
Albert Strasheim
fullung at gmail.com
Wed Nov 9 18:56:04 CET 2005
Hello
I tried your suggestion, merging the 2 L2TP connections and replacing
17/... with 17/%any, but when I start Openswan, Pluto crashes after
loading the host cert file:
Nov 9 18:25:51 vpnhost pluto[12133]: ASSERTION FAILED at connections.c:1367: isanyaddr(&c->spd.that.host_addr)
Nov 9 18:25:51 vpnhost pluto[12133]: %myid = (none)
Nov 9 18:25:51 vpnhost pluto[12133]: debug none
Nov 9 18:25:51 vpnhost pluto[12133]:
Nov 9 18:25:51 vpnhost pluto[12133]: algorithm ESP encrypt: id=2, name=ESP_DES, ivlen=8, keysizemin=64, keysizemax=64
Nov 9 18:25:51 vpnhost pluto[12133]: algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=8, keysizemin=192, keysizemax=192
Nov 9 18:25:51 vpnhost pluto[12133]: algorithm ESP encrypt: id=7, name=ESP_BLOWFISH, ivlen=8, keysizemin=40, keysizemax=448
Nov 9 18:25:51 vpnhost pluto[12133]: algorithm ESP encrypt: id=11, name=ESP_NULL, ivlen=0, keysizemin=0, keysizemax=0
Nov 9 18:25:51 vpnhost pluto[12133]: algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=8, keysizemin=128, keysizemax=256
Nov 9 18:25:51 vpnhost pluto[12133]: algorithm ESP encrypt: id=252, name=ESP_SERPENT, ivlen=8, keysizemin=128, keysizemax=256
Nov 9 18:25:51 vpnhost pluto[12133]: algorithm ESP encrypt: id=253, name=ESP_TWOFISH, ivlen=8, keysizemin=128, keysizemax=256
Nov 9 18:25:51 vpnhost pluto[12133]: algorithm ESP auth attr: id=1, name=AUTH_ALGORITHM_HMAC_MD5, keysizemin=128, keysizemax=128
Nov 9 18:25:51 vpnhost pluto[12133]: algorithm ESP auth attr: id=2, name=AUTH_ALGORITHM_HMAC_SHA1, keysizemin=160, keysizemax=160
Nov 9 18:25:51 vpnhost pluto[12133]: algorithm ESP auth attr: id=5, name=AUTH_ALGORITHM_HMAC_SHA2_256, keysizemin=256, keysizemax=256
Nov 9 18:25:51 vpnhost pluto[12133]: algorithm ESP auth attr: id=251, name=(null), keysizemin=0, keysizemax=0
Nov 9 18:25:51 vpnhost pluto[12133]:
Nov 9 18:25:51 vpnhost pluto[12133]: algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8, keydeflen=192
Nov 9 18:25:51 vpnhost pluto[12133]: algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16, keydeflen=128
Nov 9 18:25:51 vpnhost pluto[12133]: algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16
Nov 9 18:25:51 vpnhost pluto[12133]: algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20
Nov 9 18:25:51 vpnhost pluto[12133]: algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024, bits=1024
Nov 9 18:25:51 vpnhost pluto[12133]: algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536, bits=1536
Nov 9 18:25:51 vpnhost pluto[12133]: algorithm IKE dh group: id=14, name=OAKLEY_GROUP_MODP2048, bits=2048
Nov 9 18:25:51 vpnhost pluto[12133]: algorithm IKE dh group: id=15, name=OAKLEY_GROUP_MODP3072, bits=3072
Nov 9 18:25:51 vpnhost pluto[12133]: algorithm IKE dh group: id=16, name=OAKLEY_GROUP_MODP4096, bits=4096
Nov 9 18:25:51 vpnhost pluto[12133]: algorithm IKE dh group: id=17, name=OAKLEY_GROUP_MODP6144, bits=6144
Nov 9 18:25:51 vpnhost pluto[12133]: algorithm IKE dh group: id=18, name=OAKLEY_GROUP_MODP8192, bits=8192
Nov 9 18:25:51 vpnhost pluto[12133]:
Nov 9 18:25:51 vpnhost pluto[12133]: stats db_ops.c: {curr_cnt, total_cnt, maxsz} :context={0,0,0} trans={0,0,0} attrs={0,0,0}
Nov 9 18:25:51 vpnhost pluto[12133]:
Nov 9 18:25:51 vpnhost pluto[12133]: "roadwarrior-l2tp": %any:17/%any...10.2.2.251---10.2.0.13[<snip: contained value I expected to see here>]:17/%any; unrouted; eroute owner: #0
Nov 9 18:25:51 vpnhost pluto[12133]: "roadwarrior-l2tp": srcip=unset; dstip=unset; srcup=ipsec _updown; dstup=ipsec _updown;
Nov 9 18:25:51 vpnhost pluto[12133]: "roadwarrior-l2tp": CAs: '%any'...'<snip: contained expected value>'
Nov 9 18:25:51 vpnhost pluto[12133]: "roadwarrior-l2tp": ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 1
Nov 9 18:25:51 vpnhost pluto[12133]: "roadwarrior-l2tp": policy: RSASIG+ENCRYPT+TUNNEL+DONTREKEY; prio: 32,32; interface: ;
Nov 9 18:25:51 vpnhost pluto[12133]: "roadwarrior-l2tp": newest ISAKMP SA: #0; newest IPsec SA: #0;
Just to confirm, I now have the following in the configuration file:
conn roadwarrior-l2tp
leftprotoport=17/%any
rightprotoport=17/%any
also=roadwarrior
I also turned off rekeying for the road warrior connection. Replacing
the %any with 1701, Pluto works again, and seems to use the right
connection but I still have the same problem I experienced previously.
As for certificate problems, this setup works fine when I do a
connection that doesn't involve NAT traversal (i.e. road warrior on the
local network). Is there anything related to certificates that can go
wrong when doing NAT traversal?
To clear up one other detail, yes, the firewall does NAT for the
outgoing packets.
Regards
Albert
On Wed, 09 Nov 2005, Paul Wouters wrote:
> 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
More information about the Users
mailing list