[Openswan Users] CentOS/OpenSwan to Draytek site-to-site VPNrouting problem

Simon Buckner Simon at onebyte.net
Wed Aug 12 11:21:45 EDT 2009


Thanks. I've attached the files you requested. I've removed any IP
addresses and replaced them as follows:

LLL.LLL.LLL.LLL = Linux/Openswan box
GW1.GW1.GW1.GW1 = LeftNextHop
RRR.RRR.RRR.RRR = Draytek Router

Vlan10 = First WAN connection (I know it's far from ideal but last
minute requirements change from client which we're trying to get backed
out)
Vlan11 = Second WAN connection. See above.

Vlan1 = Management VLAN we're trying to VPN to.
Vlan2 = Customer VLAN.

Many thanks

Simon

-----Original Message-----
From: Peter McGill [mailto:petermcgill at goco.net] 
Sent: 12 August 2009 15:49
To: Simon Buckner; users at openswan.org
Subject: RE: [Openswan Users] CentOS/OpenSwan to Draytek site-to-site
VPNrouting problem

The tunnel itself appears to be working, but there are a number of
reasons outside of openswan why you could loose the return
packets.

If your ipsec computer is not the default gateway for your LAN and the
LAN has no routing to send the return packets to it.
If your firewall is not allowing the packets to be forwarded.
If your firewall is NATing the LAN for internet access but not excluding
the IPSec traffic from the NATing.

Some info that would help diagnose the cause would be the output of:
# The following will provide information on your openswan configuration.
ipsec verify
ipsec auto --status
# The following will detail your firewall configuration.
iptables -t filter -L -n -v
iptables -t nat -L -n -v
iptables -t mangle -L -n -v

Peter McGill
IT Systems Analyst
Gra Ham Energy Limited 

> -----Original Message-----
> From: users-bounces at openswan.org 
> [mailto:users-bounces at openswan.org] On Behalf Of Simon Buckner
> Sent: August 12, 2009 7:59 AM
> To: users at openswan.org
> Subject: [Openswan Users] CentOS/OpenSwan to Draytek 
> site-to-site VPNrouting problem
> 
> Hi,
> 
> I hope someone can help. I'm trying to get a site-to-site VPN 
> going between a Draytek router and a CentOS 
> 5.2/OpenSwan/Shorewall firewall.
> 
>  
> 
> The VPN establishes itself OK. The VPN show a connection and 
> shows packets being transmitted down the VPN from the Draytek 
> to the CentOS box.  However no packets return.
> 
>  
> 
>  
> 
> Here are the messages from /var/log/secure 
> 
>  
> 
> Aug 11 16:27:52 fw pluto[11226]: "onebyte" #6: responding to Main Mode
> 
> Aug 11 16:27:52 fw pluto[11226]: "onebyte" #6: transition 
> from state STATE_MAIN_R0 to state STATE_MAIN_R1
> 
> Aug 11 16:27:52 fw pluto[11226]: "onebyte" #6: STATE_MAIN_R1: 
> sent MR1, expecting MI2
> 
> Aug 11 16:27:52 fw pluto[11226]: "onebyte" #6: transition 
> from state STATE_MAIN_R1 to state STATE_MAIN_R2
> 
> Aug 11 16:27:52 fw pluto[11226]: "onebyte" #6: STATE_MAIN_R2: 
> sent MR2, expecting MI3
> 
> Aug 11 16:27:53 fw pluto[11226]: "onebyte" #6: ignoring 
> informational payload, type IPSEC_INITIAL_CONTACT msgid=00000000
> 
> Aug 11 16:27:53 fw pluto[11226]: "onebyte" #6: Main mode peer 
> ID is ID_IPV4_ADDR: 'RRR.RRR.RRR.RRR'
> 
> Aug 11 16:27:53 fw pluto[11226]: "onebyte" #6: transition 
> from state STATE_MAIN_R2 to state STATE_MAIN_R3
> 
> Aug 11 16:27:53 fw pluto[11226]: "onebyte" #6: STATE_MAIN_R3: 
> sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY 
> cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1024}
> 
> Aug 11 16:27:53 fw pluto[11226]: "onebyte" #6: the peer 
> proposed: 10.27.0.0/24:0/0 -> 10.0.14.0/24:0/0
> 
> Aug 11 16:27:53 fw pluto[11226]: "onebyte" #6: alloc_bytes1() 
> was mistakenly asked to malloc 0 bytes for st_skey_ar in 
> duplicate_state, please report to dev at openswan.org
> 
> Aug 11 16:27:53 fw pluto[11226]: "onebyte" #6: alloc_bytes1() 
> was mistakenly asked to malloc 0 bytes for st_skey_er in 
> duplicate_state, please report to dev at openswan.org
> 
> Aug 11 16:27:53 fw pluto[11226]: "onebyte" #6: alloc_bytes1() 
> was mistakenly asked to malloc 0 bytes for st_skey_pi in 
> duplicate_state, please report to dev at openswan.org
> 
> Aug 11 16:27:53 fw pluto[11226]: "onebyte" #6: alloc_bytes1() 
> was mistakenly asked to malloc 0 bytes for st_skey_pr in 
> duplicate_state, please report to dev at openswan.org
> 
> Aug 11 16:27:53 fw pluto[11226]: "onebyte" #7: responding to 
> Quick Mode proposal {msgid:6dac2b2a}
> 
> Aug 11 16:27:53 fw pluto[11226]: "onebyte" #7:     us: 
> 10.27.0.0/24===LLL.LLL.LLL.LLL< LLL.LLL.LLL.LLL >[+S=C]
> 
> Aug 11 16:27:53 fw pluto[11226]: "onebyte" #7:   them: 
> RRR.RRR.RRR.RRR < RRR.RRR.RRR.RRR >[+S=C]===10.0.14.0/24
> 
> Aug 11 16:27:53 fw pluto[11226]: "onebyte" #7: transition 
> from state STATE_QUICK_R0 to state STATE_QUICK_R1
> 
> Aug 11 16:27:53 fw pluto[11226]: "onebyte" #7: 
> STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
> 
> Aug 11 16:27:54 fw pluto[11226]: "onebyte" #7: transition 
> from state STATE_QUICK_R1 to state STATE_QUICK_R2
> 
> Aug 11 16:27:54 fw pluto[11226]: "onebyte" #7: 
> STATE_QUICK_R2: IPsec SA established tunnel mode 
> {ESP=>0x7bad136b <0xde297880 xfrm=3DES_0-HMAC_SHA1 
> NATOA=<invalid> NATD=<invalid>:500 DPD=enabled}
> 
>  
> 
> As I stated above if I try and access anything in the left 
> subnet (10.27.0.0) from the right subnet (10.0.14.0) I can 
> see the TX packet count increase on the Draytek but not the RX count.
> 
>  
> 
> I'm not sure what information to attach to help resolve this 
> problem. Please let me know and I will provide it for you.
> 
>  
> 
> Thanks
> 
>  
> 
> Simon
> 
> 
> This message is private and confidential. If you have 
> received this message in error, please notify us and remove 
> it from your system. Any views expressed in this message are 
> those of the individual sender, except where the sender 
> specifies and with authority, states them to be the views of 
> Onebyte. This email has been scanned for viruses and has been 
> certified as clean by Symantec, Kapersky & Clam AV. Onebyte 
> is the trading name of Landmark Computer Services and is a 
> limited company registered in England & Wales. Registered 
> number: 5329402. Registered Office 145-157 St. John Street, 
> London, EC1V 4PY 
> 
> 


This message is private and confidential. If you have received this message in error, please notify us and remove it from your system. Any views expressed in this message are those of the individual sender, except where the sender specifies and with authority, states them to be the views of Onebyte. This email has been scanned for viruses and has been certified as clean by Symantec, Kapersky & Clam AV. Onebyte is the trading name of Landmark Computer Services and is a limited company registered in England & Wales. Registered number: 5329402. Registered Office 145-157 St. John Street, London, EC1V 4PY
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ipsec.txt
Url: http://lists.openswan.org/pipermail/users/attachments/20090812/e64c763e/attachment-0004.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: iptables.filter.txt
Url: http://lists.openswan.org/pipermail/users/attachments/20090812/e64c763e/attachment-0005.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: iptables.mangle.txt
Url: http://lists.openswan.org/pipermail/users/attachments/20090812/e64c763e/attachment-0006.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: iptables.nat.txt
Url: http://lists.openswan.org/pipermail/users/attachments/20090812/e64c763e/attachment-0007.txt 


More information about the Users mailing list