<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font size="-1"><font face="Arial">Hi Peter</font></font>,<br>
<br>
Here is the output of ipsec barf | grep gghdev-brockport where gghdev
is the 10.243.102.0/24 subnet and brockport is the 10.249.100.0/24
subnet.<br>
<br>
[root@vpn etc]# ipsec barf | grep gghdev-brockport<br>
000 "gghdev-brockport":
10.243.0.0/16===216.191.52.91---216.191.52.65...66.186.93.1---209.91.185.168===10.249.0.0/16;
erouted; eroute owner: #14<br>
000 "gghdev-brockport": srcip=10.243.102.230; dstip=10.249.100.20;
srcup=ipsec _updown; dstup=ipsec _updown;<br>
000 "gghdev-brockport": ike_life: 3600s; ipsec_life: 28800s;
rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0<br>
000 "gghdev-brockport": policy: PSK+ENCRYPT+TUNNEL+PFS+UP; prio:
16,16; interface: eth0;<br>
000 "gghdev-brockport": newest ISAKMP SA: #0; newest IPsec SA: #14;<br>
000 #8: "gghdev-brockport":500 STATE_QUICK_I2 (sent QI2, IPsec SA
established); EVENT_SA_REPLACE in 26668s<br>
000 #8: "gghdev-brockport" <a class="moz-txt-link-abbreviated"
href="mailto:esp.4201bca6@209.91.185.168">esp.4201bca6@209.91.185.168</a>
<a class="moz-txt-link-abbreviated"
href="mailto:esp.271aff04@216.191.52.91">esp.271aff04@216.191.52.91</a>
<a class="moz-txt-link-abbreviated" href="mailto:tun.0@209.91.185.168">tun.0@209.91.185.168</a>
<a class="moz-txt-link-abbreviated" href="mailto:tun.0@216.191.52.91">tun.0@216.191.52.91</a><br>
000 #14: "gghdev-brockport":500 STATE_QUICK_R2 (IPsec SA established);
EVENT_SA_REPLACE in 27468s; newest IPSEC; eroute owner<br>
000 #14: "gghdev-brockport" <a class="moz-txt-link-abbreviated"
href="mailto:esp.5aae9ff4@209.91.185.168">esp.5aae9ff4@209.91.185.168</a>
<a class="moz-txt-link-abbreviated"
href="mailto:esp.2e4f4a9@216.191.52.91">esp.2e4f4a9@216.191.52.91</a> <a
class="moz-txt-link-abbreviated" href="mailto:tun.0@209.91.185.168">tun.0@209.91.185.168</a>
<a class="moz-txt-link-abbreviated" href="mailto:tun.0@216.191.52.91">tun.0@216.191.52.91</a><br>
conn gghdev-brockport<br>
May 22 14:46:33 vpn pluto[31735]: added connection description
"gghdev-brockport"<br>
May 22 14:46:38 vpn pluto[31735]: "gghdev-brockport" #8: initiating
Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP {using isakmp#4}<br>
May 22 14:46:39 vpn pluto[31735]: "gghdev-brockport" #8: transition
from state STATE_QUICK_I1 to state STATE_QUICK_I2<br>
May 22 14:46:39 vpn pluto[31735]: "gghdev-brockport" #8:
STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0x4201bca6
<0x271aff04 xfrm=AES_0-HMAC_SHA1 NATD=none DPD=none}<br>
May 22 14:46:42 vpn pluto[31735]: "gghdev-brockport" #14: responding to
Quick Mode {msgid:87763e32}<br>
May 22 14:46:42 vpn pluto[31735]: "gghdev-brockport" #14: transition
from state STATE_QUICK_R0 to state STATE_QUICK_R1<br>
May 22 14:46:42 vpn pluto[31735]: "gghdev-brockport" #14:
STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2<br>
May 22 14:46:42 vpn pluto[31735]: "gghdev-brockport" #14: transition
from state STATE_QUICK_R1 to state STATE_QUICK_R2<br>
May 22 14:46:42 vpn pluto[31735]: "gghdev-brockport" #14:
STATE_QUICK_R2: IPsec SA established {ESP=>0x5aae9ff4 <0x02e4f4a9
xfrm=AES_0-HMAC_SHA1 NATD=none DPD=none}<br>
<br>
I commmented out the klips and plutodebug lines in ipsec.conf and
restarted ipsec but ipsec barf still spewed out a lot of information so
I used grep above to glean the pertinent parts.<br>
<br>
If this is not what you need please let me know.<br>
<pre class="moz-signature" cols="72">Regards,
Arjun Datta</pre>
<br>
<br>
Peter McGill wrote:
<blockquote cite="mid:000301c8bc3e$561dffe0$350315ac@ghport3"
type="cite">
<pre wrap="">Arjun,
No the traceroute should never show any internet hosts, it should go from 10.243.102.230 to 10.249.100.20 directly (utilizing the
ipsec tunnel) and then to .22 (for that case), assuming of course that the tunnel is established.
That the traceroute uses the internet indicates a problem on 10.243.102.230, your not MASQing the ipsec traffic are you?
Give us an ipsec barf on 10.243.102.230, that should help us identify the cause of your trouble.
First make sure your debug options in ipsec.conf are set to none or commented out.
Peter McGill
IT Systems Analyst
Gra Ham Energy Limited
________________________________
From: Arjun Datta [<a class="moz-txt-link-freetext" href="mailto:arjun@greatgulfhomes.com">mailto:arjun@greatgulfhomes.com</a>]
Sent: May 22, 2008 2:23 PM
To: <a class="moz-txt-link-abbreviated" href="mailto:petermcgill@goco.net">petermcgill@goco.net</a>
Cc: <a class="moz-txt-link-abbreviated" href="mailto:users@openswan.org">users@openswan.org</a>
Subject: Re: [Openswan Users] Cannot see opposite subnet from VPN server
Hi Peter,
10.249.100.20 is the gateway for 10.249.100.0/24. There is no other gw for that subnet
It appears that my communincation breaks down at an external point on an external router outside my network:
>From 10.243.102.230:
[root@vpn ~]# traceroute 10.249.100.20
traceroute to 10.249.100.20 (10.249.100.20), 30 hops max, 40 byte packets
1 216.191.158.97 (216.191.158.97) 3.292 ms 3.116 ms 3.065 ms
2 209.112.55.121 (209.112.55.121) 1.651 ms 1.654 ms *
3 * * *
4 * * *
5 * * *
..
30 * * *
[root@vpn ~]# traceroute 10.249.100.22 - another static ip on the 10.249.100.0/24 subnet
traceroute to 10.249.100.22 (10.249.100.22), 30 hops max, 40 byte packets
1 216.191.158.97 (216.191.158.97) 3.654 ms 3.345 ms 4.666 ms
2 209.112.55.121 (209.112.55.121) 5.752 ms 6.763 ms *
3 * * *
4 * * *
5 * * *
6 * * *
...
30 * * *
Does this mean that a router owned by an ISP somewhere is blocking the returns ?
Regards,
Arjun Datta
Peter McGill wrote:
Arjun,
The route you added on 10.243.102.254 (net 10.249.100.0/24 gw 10.243.102.230) allows communication between
10.243.102.0/24 and
10.249.100.0/24. You need it for this to work.
However, no routes on 10.243.102.254 will affect communication between 10.243.102.230 and 10.249.100.0/24, as the
traffic will never
reach 10.243.102.254.
Do you have a different gateway for the 10.249.100.0/24 subnet other than 10.249.100.20, like you do on the
10.243.102.0/24 subnet?
In that case you will need a route on it (10.249.100.?) also, (net 10.243.102.0/24 gw 10.249.100.20).
If that is not the case I suggest the following on 10.243.102.230:
traceroute 10.249.100.20
traceroute 10.249.100.(test host)
Which will indicate where the communication breaks down.
Peter McGill
IT Systems Analyst
Gra Ham Energy Limited
________________________________
From: Arjun Datta [<a class="moz-txt-link-freetext" href="mailto:arjun@greatgulfhomes.com">mailto:arjun@greatgulfhomes.com</a>]
Sent: May 21, 2008 7:58 PM
To: Matthew Hall
Cc: Paul Wouters; <a class="moz-txt-link-abbreviated" href="mailto:users@openswan.org">users@openswan.org</a>; <a class="moz-txt-link-abbreviated" href="mailto:petermcgill@goco.net">petermcgill@goco.net</a>
Subject: Re: [Openswan Users] Cannot see opposite subnet from VPN server
Thank you guys - Paul, Peter and Matthew.
I applied the leftsourcip= and rightsourceip= changes advocated and suggested, and I can ping the
10.243.102.x subnet from
the 10.249.100.20 VPN server now.
However I still cannot ping the 10.249.100.x subnet from the 10.243.102.230 VPN server.
Now, the gateway for the 10.243.102.x domain is NOT the 10.243.102.230 machine, the gateway is
10.243.102.254.
I have manually added routes to the latter .254 machine to route all traffic for the 10.249.100.x subnet
through the
10.243.102.230 machine (VPN Peer/Server). Sop I have to tweak something on the .254 machine to allow 10.243.102.230
to ping the
10.249.100 subnet ?
>I have a VPN tunnel established between two subnets:
>10.243.102.x - the vpn server is 10.243.102.230 - 2.6.22.9-61.fc6, Linux Openswan U2.4.5/K2.6.22.9-61.fc6
(netkey)
>10.249.100.x - the vpn server is 10.249.100.20 - 2.6.23.15-80.fc7, Linux Openswan U2.4.7/K2.6.23.15-80.fc7
(netkey)
Regards,
Arjun Datta
Matthew Hall wrote:
Paul Wouters wrote:
On Thu, 15 May 2008, Matthew Hall wrote:
I know that one cannot ping the actual vpn server(s) themselves, so the
above would be normal.
But, it also appears the VPN servers themselves cannot see anything in
the opposite subnet. Is there a way around this ?
I need to pull something from one machine in the 10.243.102.x subnet
onto the 10.249.100.20 machine.
This will be because when it's pinging the other side, the source
address is not in the local range provided by the vpn - ie. it's source
address will be whatever the IP is of the interface with your default
gateway, so it doesn't get routed over the vpn.
If you bind the ping to it's 'inside' interface it should work - ie.
ping 10.243.102.x -I 10.249.100.20.
You can workaround this by setting the 'defaultsource' for pluto; on
A better was is to specify leftsourceip= and rightsourceip= in the conn,
Setting it globally would limit you you to do this only on one conn.
I didn't know that existed - makes my life easier :)
Thanks Paul.
Matt
</pre>
</blockquote>
</body>
</html>