[Openswan Users] Cannot make openswan working...
Andriy Lesyuk
s-andy at in.if.ua
Wed Apr 30 15:00:20 EDT 2008
Well, the same without grsecurity (so I guess it has nothing to do with
the problem)...
> 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/d31e5c37/attachment-0001.html
More information about the Users
mailing list