Hi! I'll apologize if this first answer isn't sufficient. I'm flying west in ~7 hours, and I'm scrambling around packing and fixing computers (see my blog about using a freezer as a data recovery tool).
Anyway... On Sun, May 18, 2008 at 01:04:30PM -0400, Chaskiel Grundman wrote: > I am trying to set up a vpn tunnel between an x86 opensolaris 2008.05 > host and a cisco 3000 series vpn concentrator. The vpn connections are > authenticated with certificates only, so I cannot use vpnc. I have > successfully set up strongswan on linux, with this gateway, so I think > it should be possible to do this with "standard" ipsec components. The > concentrator does not use xauth, and the vpn group I am connecting to > uses static addresses and no mode config. Our IKE doesn't support xauth or mode-config anyway, so good call. > After ike, ipsec, and the tunnel are set up as specified below, and I > try to send traffic down the tunnel, nothing seems to happen. in.iked > doesn't log anything (it is started), and no packets are transmitted > (checked with tcpdump on the nat router). nwam has been disabled. If in.iked doesn't log anything, it means something in-kernel has decided the packet(s) in question don't need IPsec. > One problem I have is that I do not know what to use for the tunnel > interface's "dest address" (not the "tunnel destination", that's the > vpn gateway's address). The vpn gateway only has a single address. it > certainly does not have an address on each of the tunneled networks, > as the example in the ip services guide > (http://docs.sun.com/app/docs/doc/816-4554/ipsec-mgtasks-vpn-4?l=en&a=view) > seems to require. It doesn't really require a match, it just requires something in the destination. You also could treat the tunnel as an ethernet-like interface with your address and a prefix. > A possibly-related problem is that I do not know the right way to > specify what networks should be tunneled. Just route them? Tunnels in OpenSolaris are treated like any other point-to-point network interface. > How does > solaris know what ipsec SAs and policies to create? That's what your ipsecconf(1m) input does. > Would installing SXCE and clearview make this easier? The clearview > documentation still refers to interface dest addresses, so I am > guessing that it will not. Probably not. > (redacted) networks in my configuration: > 192.168.1.0/24: my home nat > 4.0.0.0/8: my provider's network > 10.10.0.0/16: one of my employers networks, accessible via the > internet, but some protocols are filtered if not using vpn > 10.20.0.0/16: one of my employers networks, accessible via the > internet, but some protocols are filtered if not using vpn > 10.30.0.0/16: one of my employers networks, NOT accessible via the internet. > 10.31.0.0/16: network that vpn clients are registered in. <SNIP!> ASCII art is hard, don't worry. I read your second note. > My ike config looks like this: > > cert_root "[redacted]" > > use_http > > p2_lifetime_secs 86400 > local_id_type dns > p1_xform { oakley_group 2 encr_alg 3des-cbc auth_alg sha1 auth_method rsa_sig > } > > { > local_addr 0.0.0.0 > remote_addr 10.10.5.212 > local_id "DNS=opensolaris.example.com" > remote_id "[redacted]" > } The "remote_addr" should be the external address of the VPN concentrator, and according to your second note, that's what it is. Funny that net-10 is reachable from the Internet, but maybe that's a redaction on your part. > My ipsecinit.conf looks like this: > > {laddr 192.168.1.17 dir both} bypass{} First mistake. You need to have the address of the tunnel (10.31.25.5) here. > {tunnel ip.tun0 negotiate tunnel} ipsec {encr_algs 3des encr_auth_algs > sha1 sa shared} This means all ip.tun0 traffic will be negotiated with these IKE Phase 2 selectors: initiator-local: 0.0.0.0/0 initiator-remote: 0.0.0.0/0 You may wish to say instead: {tunnel ip.tun0 negotiate tunnel laddr 10.31.25.5/32} ipsec .... And "sa shared" is redundant for tunnels. > The tunnel is brought up like this (after plumb): > ifconfig ip.tun0 10.31.25.5 10.10.5.209 tsrc 192.168.1.17 tdst 10.10.5.212 > or > ifconfig ip.tun0 10.31.25.5 10.10.5.212 tsrc 192.168.1.17 tdst 10.10.5.212 You need to replace 10.10.5.209 or 10.10.5.212 with the VPN concentrator's address that your firm's internal network sees. If you're inside your firm's network (via some other way), what address is your VPN concentrator? If for some obscure reason it has none, pick it's next-hop internal router. You can, of course, not specify a destination address: ifconfig ip.tun0 10.31.25.5/32 tsrc 192.168.1.17 tdst 10.10.5.212 And pretend it's an ethernet-like interface. Finally, you need to specify routes for your internal networks. If you configure ip.tun0 as a point-to-point with <internal-addr>, try these: route add 10.10.0.0/16 <internal-addr> route add 10.20.0.0/16 <internal-addr> Or if you choose the ethernet-like route, these should work instead: route add 10.10.0.0/16 -interface 10.31.25.5 route add 10.20.0.0/16 -interface 10.31.25.5 Does this help? Dan _______________________________________________ networking-discuss mailing list networking-discuss@opensolaris.org
