[Openswan Users] Cannot make openswan working...

[Andriy Lesyuk]

Tried using NETKEY - the same result. Just after the VPN connection has 
been established all connectivity (including ping and ssh) from my home 
IP with the server gets lost. However it returns automatically in some 
time (around 30 mins). This seems to be some kind of kernel issue (not 
sure if openswan itself is able to do things like these). Does anyone 
have an idea what can lead to this? By the way - in addition to klips 
and natt patch I'm using grsecurity patch... I guess this can be 
grsecurity issue. Does anyone know if grsecurity works well with IPSec?

P.S. Anyway going to try without grsecurtiy...

I wonder if someone can answer on the question: Can 192.168.14.0/24 be 
used on the client side if 192.168.0.0/20 is used on the server side?

My network looks like this:
192.168.14.0/24 (me) -> y.y.y.y (my home external ip) -> x.x.x.x 
(openswan server) -> 192.168.0.0/20 (zone in LAN of the server)
where y.y.y.y and x.x.x.x are real IP addresses.

> Hello,
>
> I have spent many hours trying to make Openswan working. No success 
> for now.
>
> First, this is my configuration:
>
> o Openswan 2.4.6
> o Debian kernel 2.6.18 patched with klips and natt (for Openswan 
> version 2.4.6).
>
> /etc/ipsec.conf is:
>
>   1.
>       version 2.0
>   2.
>        
>   3.
>       config setup
>   4.
>           nat_traversal=yes
>   5.
>           interfaces=ipsec0=eth1
>   6.
>           rp_filter=0
>   7.
>           syslog=local6.info
>   8.
>           #plutodebug=all
>   9.
>           dumpdir=/etc/ipsec.d
>  10.
>          
>       virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!10.44.68.0/24,%v4:!192.168.0.0/20,%v4:!172.27.172.0/24
>  11.
>           strictcrlpolicy=yes
>  12.
>        
>  13.
>       conn nung-server
>  14.
>           type=tunnel
>  15.
>           left=X.X.X.X
>  16.
>           leftcert=ipsec-cert.pem
>  17.
>           right=%any
>  18.
>           rightsubnet=vhost:%no,%priv
>  19.
>           rightrsasigkey=%cert
>  20.
>           leftprotoport=17/1701
>  21.
>           rightprotoport=17/1701
>  22.
>           authby=rsasig
>  23.
>           keyingtries=3
>  24.
>           pfs=no
>  25.
>           auto=add
>  26.
>           rekey=no
>  27.
>        
>  28.
>       # Disable Opportunistic Encryption
>  29.
>       include /etc/ipsec.d/examples/no_oe.conf
>
> /etc/ipsec.secrets:
>
>   1.
>       : RSA /etc/ipsec.d/private/ipsec-key.pemversion 2.0
>
> For now it tries to connect and I don't see any errors... Before this 
> pluto used to crash often (eg, with different value for rightsubnet). 
> The problem is that when it seems to be connected any connectivity 
> with X.X.X.X seems to disappear. Technicaly it looks like there was 
> added a rule to firewall on X.X.X.X which looks like:
>
> iptables -I INPUT -s Y.Y.Y.Y -j DROP
>
> But no firewall rules there. In other words - no packets arrive to 
> X.X.X.X from Y.Y.Y.Y any more...
>
> This is what I see in logs:
>
>   1.
>       Apr 27 02:16:57 base pluto[17849]: packet from y.y.y.y:500:
>       ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000004]
>   2.
>       Apr 27 02:16:57 base pluto[17849]: packet from y.y.y.y:500:
>       ignoring Vendor ID payload [FRAGMENTATION]
>   3.
>       Apr 27 02:16:57 base pluto[17849]: packet from y.y.y.y:500:
>       received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
>       method set to=106
>   4.
>       Apr 27 02:16:57 base pluto[17849]: packet from y.y.y.y:500:
>       ignoring Vendor ID payload [Vid-Initial-Contact]
>   5.
>       Apr 27 02:16:57 base pluto[17849]: "nung-server"[4] y.y.y.y #5:
>       responding to Main Mode from unknown peer y.y.y.y
>   6.
>       Apr 27 02:16:57 base pluto[17849]: "nung-server"[4] y.y.y.y #5:
>       transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
>   7.
>       Apr 27 02:16:57 base pluto[17849]: "nung-server"[4] y.y.y.y #5:
>       STATE_MAIN_R1: sent MR1, expecting MI2
>   8.
>       Apr 27 02:16:57 base pluto[17849]: "nung-server"[4] y.y.y.y #5:
>       NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03:
>       peer is NATed
>   9.
>       Apr 27 02:16:57 base pluto[17849]: "nung-server"[4] y.y.y.y #5:
>       transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
>  10.
>       Apr 27 02:16:57 base pluto[17849]: "nung-server"[4] y.y.y.y #5:
>       STATE_MAIN_R2: sent MR2, expecting MI3
>  11.
>       Apr 27 02:16:57 base pluto[17849]: "nung-server"[4] y.y.y.y #5:
>       Main mode peer ID is ID_DER_ASN1_DN: 'C=UA, ST=Ivano-Frankivsk,
>       L=Ivano-Frankivsk, O=National University of Oil and Gas,
>       OU=Software & Networking Lab., CN=email, E=email'
>  12.
>       Apr 27 02:16:57 base pluto[17849]: "nung-server"[4] y.y.y.y #5:
>       I am sending my cert
>  13.
>       Apr 27 02:16:57 base pluto[17849]: "nung-server"[4] y.y.y.y #5:
>       transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
>  14.
>       Apr 27 02:16:57 base pluto[17849]: | NAT-T: new mapping
>       y.y.y.y:500/61121)
>  15.
>       Apr 27 02:16:57 base pluto[17849]: "nung-server"[4] y.y.y.y #5:
>       STATE_MAIN_R3: sent MR3, ISAKMP SA established
>       {auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192 prf=oakley_sha
>       group=modp2048}
>  16.
>       Apr 27 02:16:57 base pluto[17849]: "nung-server"[4] y.y.y.y #6:
>       responding to Quick Mode {msgid:284397ed}
>  17.
>       Apr 27 02:16:57 base pluto[17849]: "nung-server"[4] y.y.y.y #6:
>       transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
>  18.
>       Apr 27 02:16:57 base pluto[17849]: "nung-server"[4] y.y.y.y #6:
>       STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
>  19.
>       Apr 27 02:16:57 base pluto[17849]: "nung-server"[4] y.y.y.y #6:
>       transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
>  20.
>       Apr 27 02:16:57 base pluto[17849]: "nung-server"[4] y.y.y.y #6:
>       STATE_QUICK_R2: IPsec SA established {ESP=>0x5f05f00d
>       <0x5aad9757 xfrm=3DES_0-HMAC_MD5NATD=y.y.y.y:61121 DPD=none}
>
> As I understood - no errors here, right?
>
> I wonder if this is due to KLIPS? Will NETKEY solve the problem? I 
> would like to remain on Openswan 2.4.6... I know that there is newer 
> versiob but this one is in official Debian repository so it is easier 
> to maintain. Any suggestion how to solve the issue? Maybe there are 
> some errors in my config file? Any way I don't understand how and why 
> I can loose any connectiovity with the server after trying to connect 
> (ping, ssh etc)...
>
> But I have some thoughts:
>
> The virtual_private is defined as follows:
>
> %v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!10.44.68.0/24,%v4:!192.168.0.0/20,%v4:!172.27.172.0/24
>
> That is all possible virtual nets minus nets used on the server 
> (10.44.68.0/24, 192.168.0.0/20, 172.27.172.0/24). On the client side I 
> use 192.168.14.0/24 for local net. May be this is the problem? Can 
> 192.168.14.0/24 be used on the client side if 192.168.0.0/20 is used 
> on the server side? If not - how I can connect to the server then? May 
> I exclude 192.168.0.0/20 from the virtual_private? What if I do? If 
> 192.168.14.0/24 cannot be used with Openswan because the server uses 
> 192.168.0.0/20 then, perhaps, Openswan is not what I need... :( But I 
> believe there should be some solution? For example, can I create some 
> special net for Openswan so it won't care about local nets (like it is 
> done in OpenVPN)?
>
> Thanks! Any help will be greatly appreciated.
> Andriy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20080430/f883b1d9/attachment.html