[Openswan Users] Openswan 2.4, FC4 Question

[Darren Ellis]

Hi,

I'm stumped by the kernel 2.6 changes to openswan use.

On the server end, I have a Fedora Core 4 (FC4) linux server with 
openswan 2.4 installed.  Eth0 is on the Internet, Eth1 is private.  I 
can ping eth0 from the outside; I can ping eth1 from the inside.  IP 
forwarding is enabled.

VPN Server:
Eth0 x.y.z.58/27, gw x.y.z.33 (External, public)
Eth1 172.20.7.145/21

The 172.20.0.0 LAN has it's default route s 172.20.0.1.  Name servers 
are internal at 172.20.7.194 and 172.20.7.194.  They resolve against an 
internal domain and then recurse anything not found in the internal domain.

ipsec verify looks good:
[root at vpn ~]# ipsec verify
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                                 [OK]
Linux Openswan U2.4.0/K2.6.12-1.1447_FC4 (netkey)
Checking for IPsec support in kernel                            [OK]
Checking for RSA private key (/etc/ipsec.secrets)               [OK]
Checking that pluto is running                                  [OK]
Two or more interfaces found, checking IP forwarding            [OK]
Checking NAT and MASQUERADEing                             
Checking for 'ip' command                                       [OK]
Checking for 'iptables' command                                 [OK]
Checking for 'curl' command for CRL fetching                    [OK]
Checking for 'setkey' command for NETKEY IPsec stack support    [OK]
Opportunistic Encryption Support                                [DISABLED]
[root at vpn ~]#

On the client end, I have Windows 2000 and the Greenbow VPN client.  The 
Win2K workstation is behind a Linux firewall providing NAT via Shorewall 
firewall.  I have a self-signed CA built and certificates properly 
generated and signed.

Client side:
Win2K: 192.168.0.62/24 (DHCP), gw 192.168.0.1, name servers are Adelphias.
Linux-Shorewall firewall:
Eth1:  192.168.0.1
Eth0:  Dynamic, Adelphia, currently 70.33.197.36

I have openswan and greenbow correctly configured in that I have a 
successful tunnel.  Below is my ipsec.conf.

version 2.0     # conforms to second version of ipsec.conf specification

# basic configuration
config setup
        # plutodebug / klipsdebug = "all", "none" or a combation from below:
        # "raw crypt parsing emitting control klips pfkey natt x509 private"
        # eg:
        # plutodebug="control parsing"
        #
        # Only enable klipsdebug=all if you are a developer
        #
        # NAT-TRAVERSAL support, see README.NAT-Traversal
        # nat_traversal=yes
        # virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%4:172.16.0.0/12
        # Debug-logging controls:  "none" for (almost) none, "all" for lots.
        interfaces=%defaultroute
        nat_traversal=yes
        # crlcheckinterval=600
        # strictcrlpolicy=yes
        # klipsdebug=all
        klipsdebug=none
        # plutodebug="control parse"
        plutodebug=none
       virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16

conn %default
        leftrsasigkey=%cert
        rightrsasigkey=%cert
        # Left security gateway, subnet behind it, next hop toward right.
        rekey=no
        keyingtries=1
        compress=yes
        disablearrivalcheck=no
        left=%defaultroute
        authby=rsasig

#Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf

# left = local (vpn)
# right = remote (DGE Win2K Box, dynamic)
conn dgevpn-net
       leftsubnet=172.20.0.0/21
        also=dgevpn

conn dgevpn
        # VPN connection from Darren's Win2K machine
        rekey=yes
        keyingtries=1
        authby=rsasig
        leftrsasigkey=%cert
        left=%defaultroute
        rightrsasigkey=%cert
        rightsubnet=vhost:%no,%priv
        leftcert=vpn.pem
        rightcert=dgecert.pem
        right=%any
        pfs=yes
        auto=add

There is a server on the 172.20.0.0/21 LAN, 172.200.7.193 that I am 
trying to access.  I am unable to ping it.  I found that I had an 
asymetric routing problem as the VPN server is not the default gateway.  
So, I added a route to the default gateway to forward all traffice 
destined for the 192.168.0.0/24 LAN back to the VPN server.

Ethereal reports pings reaching 172.20.7.193 from 192.168.0.62 and 
172.20.7.193 replies to 192.168.0.62.  The replies are routed to 
172.20.0.1, which forwards them to 172.20.7.145 via a simple static route.

Clearly, I misunderstand somethig or have misconfigured something  as I 
am not able to get traffic to flow properly over the established 
tunnel.  I have googled for help, as well as reviewed the openswan 2.4 
docs.  Unfortunately, I am using 2.6.11 or newer kernels, and there 
seems to be very little documenation on the "new" way of doing things.  
I have successfully used openswan 2.3.1 with 2.4 kernels, but they had 
ipsec0 interfaces to work with.

My questions are as follows:
1.  What other information do I need to provide to the list?  This is a 
fairly complex configuration, at least for me, though it's real-world 
common, and I'm sure I omitted a detail or three.
2.  Do I need to be using racoon or KLIPS?  I think I should be using 
KLIPS and am doing so at the moment.

    [root at vpn ~]# rpm -qa | grep openswan
    openswan-2.4.0-1
    openswan-klips-2.4.0-2.6.12_1.1447_FC4_1
    openswan-doc-2.4.0-1
    [root at vpn ~]#


3.  Is there a HOWTO doc somewhere that details the steps and requirements?

Thanks.

Darren

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20050918/b55cb64e/attachment.htm