[Openswan Users] Cannot make openswan working...
Peter McGill
petermcgill at goco.net
Wed Apr 30 10:07:17 EDT 2008
> 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?
General routing rules apply.
As long as there are no 192.168.14.0/24 hosts in the 192.168.0.0/20 subnet then everything will work fine,
as ip routing will choose the most specific route for each packet. For example:
192.168.0.0/20 (bad subnet: 192.168.14.0/24) (ok subnets: 192.168.0.0/21, 192.168.8.0/22, 192.168.12.0/23, 192.168.15.0/24)
|
[openswan server]
|
Internet
|
[remote router]
|
192.168.14.0/24
|
[l2tp (windows/mac/linux) client]
You may also need to set one of the following on the server:
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:192.168.14.0/24,%v4:!
172.27.172.0/24
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/21,%v4:!192.168.8.0/22,%v4:!
192.168.12.0/23,%v4:!192.168.15.0/24,%v4:!172.27.172.0/24
Peter McGill
________________________________
From: users-bounces at openswan.org [mailto:users-bounces at openswan.org] On Behalf Of Andriy Lesyuk
Sent: April 30, 2008 3:44 AM
To: users at openswan.org
Subject: Re: [Openswan Users] Cannot make openswan working...
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
More information about the Users
mailing list