[Openswan Users] CentOS/OpenSwan to Draytek site-to-site VPNrouting problem
Simon Buckner
Simon at onebyte.net
Wed Aug 12 15:14:18 EDT 2009
Thanks very much for that. I'm using NETKEY so that clears that one up
for me. I'm going to raise this on the Shorewall mailing list as this is
more appropriate for them. Once again thanks for you help.
Simon
-----Original Message-----
From: Peter McGill [mailto:petermcgill at goco.net]
Sent: 12 August 2009 19:31
To: Simon Buckner; users at openswan.org
Subject: RE: [Openswan Users] CentOS/OpenSwan to Draytek site-to-site
VPNrouting problem
Not if your using NETKEY.
There is two IPSec stacks that can be used in the Linux kernel, NETKEY
and KLIPS.
NETKEY is the default for 2.6 kernels, and most likely what your using.
KLIPS was developed with Openswan and is not compiled into the kernel by
default,
KLIPS was the only choice prior to the development of NETKEY with the
2.6 kernel.
The interfaces line is only used by KLIPS, it will create an ipsec0
interface
for tunnel traffic, separating the tunnel traffic from the public
interfaces.
It also tells KLIPS which interfaces to bind to for IPSec.
NETKEY does not use interfaces line, it automatically binds to all
available interfaces.
It does not create ipsecX interfaces, but instead returns the
unencrypted packets
back to the interface it received the encrypted packets on (your public
interface).
This is important to understand to build your firewall rules correctly.
To describe how packets traverse the system on each stack, consider this
iptables diagram:
Each IPSec packet traverses the iptables system twice, once for
encrypted
ipsec packets, and a second time for the unencrpted traffic payload.
-> PREROUTING -> Routing -> FORWARD -> POSTROUTING ->
Decision ^
| |
v |
INPUT -> Local -> OUTPUT
Process
For a system with left/eth1=123.45.67.89, eth0=192.168.0.1,
right=98.76.54.32,
rightsubnet=192.168.1.0/24, leftsubnet=192.168.0.0/24:
ping=unencrypted ping packet between remote (right)subnet and local
(left)subnet.
esp=encrypted ipsec packet (containing ping).
The flow on the local box goes like this:
ping request:
esp -> PREROUTING -> INPUT -> openswan -> ping ->
PREROUTING -> FORWARD -> POSTROUTING
NETKEY: (in=eth1 src=98... dst=123... prot=50) (in=eth1 out=eth0
src=...1.0/24 dst=...0.0/24 ping)
KLIPS: (in=eth1 src=98... dst=123... prot=50) (in=ipsec0 out=eth0
src=...1.0/24 dst=...0.0/24 ping)
ping reply:
ping -> PREROUTING -> FORWARD -> POSTROUTING -> openswan -> esp
-> OUTPUT -> POSTROUTING
NETKEY: (in=eth0 out=eth1 src=...0.0/24 dst=...1.0/24 ping) (out=eth1
src=123... dst=98... prot=50)
KLIPS: (in=eth0 out=ipsec0 src=...0.0/24 dst=...1.0/24 ping) (out=eth1
src=123... dst=98... prot=50)
The only difference (for firewalling) between NETKEY and KLIPS is what
interface the "ping" packets
use for the "public" interface. With NETKEY they use the real public
interface, KLIPS uses ipsec0.
Peter McGill
IT Systems Analyst
Gra Ham Energy Limited
> -----Original Message-----
> From: Simon Buckner [mailto:Simon at onebyte.net]
> Sent: August 12, 2009 1:05 PM
> To: petermcgill at goco.net; users at openswan.org
> Subject: RE: [Openswan Users] CentOS/OpenSwan to Draytek
> site-to-site VPNrouting problem
>
> 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
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