[Openswan Users] Cannot see opposite subnet from VPN server
Arjun Datta
arjun at greatgulfhomes.com
Thu May 22 17:02:16 EDT 2008
Gotcha. Attached.
I just wanted to make sure that this IS what you wanted because, often
the bane of mailing-lists (and their mods) is either too much
(redundant) information or too little =)
Regards,
Arjun Datta
Peter McGill wrote:
> Arjun,
>
> Actually we need to see most of that output, ipsec barf outputs a lot
> of useful debugging info.
> We could ask for it one command at a time, but this way is much faster
> for us to fix your problem.
> Just send it to a file, ipsec barf > ipsec_barf.txt and attach the
> file to the email.
> Basically it sends ipsec.conf and ipsec.secrets (with keys replaced
> with checksums),
> netstat's, ifconfig's, logs, iptables (firewall rules), all the ipsec
> scripts and a few other things.
> In other words how your computers networks are configured, how ipsec
> is configured, logs, etc...
>
>
> Peter McGill
> IT Systems Analyst
> Gra Ham Energy Limited
>
>
>
> ------------------------------------------------------------------------
> *From:* Arjun Datta [mailto:arjun at greatgulfhomes.com]
> *Sent:* May 22, 2008 3:51 PM
> *To:* petermcgill at goco.net
> *Subject:* Re: [Openswan Users] Cannot see opposite subnet from
> VPN server
>
> Hi Peter,
>
> 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.
>
> [root at vpn etc]# ipsec barf | grep gghdev-brockport
> 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
> 000 "gghdev-brockport": srcip=10.243.102.230;
> dstip=10.249.100.20; srcup=ipsec _updown; dstup=ipsec _updown;
> 000 "gghdev-brockport": ike_life: 3600s; ipsec_life: 28800s;
> rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
> 000 "gghdev-brockport": policy: PSK+ENCRYPT+TUNNEL+PFS+UP; prio:
> 16,16; interface: eth0;
> 000 "gghdev-brockport": newest ISAKMP SA: #0; newest IPsec SA: #14;
> 000 #8: "gghdev-brockport":500 STATE_QUICK_I2 (sent QI2, IPsec SA
> established); EVENT_SA_REPLACE in 26668s
> 000 #8: "gghdev-brockport" esp.4201bca6 at 209.91.185.168
> esp.271aff04 at 216.191.52.91 tun.0 at 209.91.185.168 tun.0 at 216.191.52.91
> 000 #14: "gghdev-brockport":500 STATE_QUICK_R2 (IPsec SA
> established); EVENT_SA_REPLACE in 27468s; newest IPSEC; eroute owner
> 000 #14: "gghdev-brockport" esp.5aae9ff4 at 209.91.185.168
> esp.2e4f4a9 at 216.191.52.91 tun.0 at 209.91.185.168 tun.0 at 216.191.52.91
> conn gghdev-brockport
> May 22 14:46:33 vpn pluto[31735]: added connection description
> "gghdev-brockport"
> May 22 14:46:38 vpn pluto[31735]: "gghdev-brockport" #8:
> initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP {using isakmp#4}
> May 22 14:46:39 vpn pluto[31735]: "gghdev-brockport" #8:
> transition from state STATE_QUICK_I1 to state STATE_QUICK_I2
> 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}
> May 22 14:46:42 vpn pluto[31735]: "gghdev-brockport" #14:
> responding to Quick Mode {msgid:87763e32}
> May 22 14:46:42 vpn pluto[31735]: "gghdev-brockport" #14:
> transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
> May 22 14:46:42 vpn pluto[31735]: "gghdev-brockport" #14:
> STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
> May 22 14:46:42 vpn pluto[31735]: "gghdev-brockport" #14:
> transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
> 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}
>
> 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.
>
> If this is not what you need please let me know.
>
> Regards,
>
> Arjun Datta
>
>
>
> Peter McGill wrote:
>> 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 [mailto:arjun at greatgulfhomes.com]
>> Sent: May 22, 2008 2:23 PM
>> To: petermcgill at goco.net
>> Cc: users at openswan.org
>> 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 at 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 at 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 [mailto:arjun at greatgulfhomes.com]
>> Sent: May 21, 2008 7:58 PM
>> To: Matthew Hall
>> Cc: Paul Wouters; users at openswan.org; petermcgill at goco.net
>> 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
>>
>>
>>
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20080522/010aeb0f/attachment-0001.html
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ipsec_barf_vpn.txt
Url: http://lists.openswan.org/pipermail/users/attachments/20080522/010aeb0f/attachment-0001.txt
More information about the Users
mailing list