[Openswan Users] CentOS/OpenSwan to Draytek site-to-site VPNrouting problem
Simon Buckner
Simon at onebyte.net
Wed Aug 12 13:05:09 EDT 2009
Thanks. I have a feeling my next stop is going to be the shorewall
mailing lists but that is good as I'm moving forward which if far better
than yesterday. Can you just confirm or deny the following for me? I
have the following in my ipsec.conf.
interfaces="ipsec0=vlan10"
Should that create an interface viewable via ifconfig?
Thanks
Simon
-----Original Message-----
From: Peter McGill [mailto:petermcgill at goco.net]
Sent: 12 August 2009 17:23
To: Simon Buckner; users at openswan.org
Subject: RE: [Openswan Users] CentOS/OpenSwan to Draytek site-to-site
VPNrouting problem
You will need to edit your shorewall configuration.
I haven't used shorewall much so I'm not sure the exact changes you need
to make,
but it needs to exempt your IPSec traffic from getting MASQ'd.
You MASQ rule(s) are altering the IPSec traffic preventing the return
packets from entering the tunnel.
> Chain POSTROUTING (policy ACCEPT 471 packets, 26266 bytes)
> pkts bytes target prot opt in out source
destination
> 180K 14M vlan10_masq all -- * vlan10 0.0.0.0/0
0.0.0.0/0
> Chain vlan10_masq (1 references)
> pkts bytes target prot opt in out source
destination
> 0 0 MASQUERADE all -- * * 10.27.0.0/24
0.0.0.0/0
> 180K 14M MASQUERADE all -- * * 10.27.1.0/24
0.0.0.0/0
> 0 0 MASQUERADE all -- * * 10.27.2.0/24
0.0.0.0/0
Peter McGill
IT Systems Analyst
Gra Ham Energy Limited
> -----Original Message-----
> From: Simon Buckner [mailto:Simon at onebyte.net]
> Sent: August 12, 2009 11:22 AM
> To: petermcgill at goco.net; users at openswan.org
> Subject: RE: [Openswan Users] CentOS/OpenSwan to Draytek
> site-to-site VPNrouting problem
>
> 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
>
>
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
More information about the Users
mailing list