[Openswan Users] IPSec config and passthrough on Draytek 2820n

Daniel Cave dan.cave at me.com
Sat Jan 12 06:04:37 EST 2013


Hi Paul, (and Nick for his previous reply)

I have turned off IPsec on the 2820 as you will have seen by the netcat output from fcs01 to the static IP.  You'll also notice that the ipsec phase 2 completes correctly as I did when fcs01 connected straight to the 2820n, however i'm not getting any routing.

I removed the erroneous space in my config but apparently that does not appear to have made any difference. 

i still get the respective ipsec tunnel established messages from both sides

Jan 12 10:56:36 fcs01 pluto[26002]: "swan" #12: STATE_QUICK_R2: IPsec SA established tunnel mode {ESP=>0x498582e0 <0x7026337a xfrm=3DES_0-HMAC_SHA1 NATOA=none NATD=none DPD=none}


Jan 12 10:58:10 centos62 pluto[12250]: "fcs01" #6: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP=>0x7026337a <0x498582e0 xfrm=3DES_0-HMAC_SHA1 NATOA=none NATD=none DPD=enabled}

But i'm still unable to ping both endpoints.

Anyone got any clues ?


> I can think of a number of reasons why you would not necessarily wish to terminate a VPN on a Draytek router. Mostly down to reliability although I agree that the interoperability is good with OpenSwan.
> 
> You do not need to use IPsec passthrough, but you will need to switch off the IPsec functions of the Draytek router if you are using nated address space. NAT-t (encap) will work correctly so long as the Draytek does not own port 4500.
> 
> Regards Paul
> 
> -----Original Message-----
> From: users-bounces at lists.openswan.org [mailto:users-bounces at lists.openswan.org] On Behalf Of Nick Howitt
> Sent: 10 January 2013 18:22
> To: Daniel Cave
> Cc: users at lists.openswan.org
> Subject: Re: [Openswan Users] IPSec config and passthrough on Draytek 2820n
> 
> Can I ask a stupid question? Why are you not terminating the IPSec in the 2820n? It is a great little router. Configure it with ESP with Encryption and Authentication, AES256/DH14, PFS and it will interoperate fine with Openswan.
> 
> Anyway, back to your question. I believe a blank line marks the end of a conn so it is not seeing your last four parameters. In the same way something at the beginning of the line marks a new conn - even if it is a #. An indented # will comment out a parameter OK.
> 
> Regards,
> 
> Nick
> 
> On 09/01/2013 22:43, Daniel Cave wrote:
>> Hi there ipsec'ers
>> 
>> I've been playing with a two host config
>> 
>> IPsec box 1: hostname FCS01 (on internet)
>> 
>> Internet IP Address.
>> Local ip 10.49.73.1/24
>> Centos 5.8.  Linux Openswan U2.6.38/K2.6.18-308.4.1.el5debug (netkey)
>> 
>> 
>> It also has two other IPsec connections (another openSwan net and a net gear wifi router ipsec networks so I can ping the other two endpoints.)  - this is my 'hub'
>> 
>> Ipsec box 2 - hostname centos62.
>> 
>> @Home - CentOS 6.2 sat behind a Draytek 2820n running Linux Openswan
>> U2.6.32/K2.6.32-220.el6.x86_64 (netkey) on the same lan.
>> 192.168.72.0/24
>> 
>> I have setup port forwarding on my 2820 to forward UDP 500/4500 to the swan box.
>> 
>> When i set the respective configs, on Swan and fcs01 to bring up the tunnel at both ends,  and they run up and i get this on both endpoints.
>> 
>> on fcs01 -
>> 
>> Jan  9 22:22:48 fcs01 pluto[16053]: "swan" #25: responding to Main
>> Mode Jan  9 22:22:48 fcs01 pluto[16053]: "swan" #25: transition from
>> state STATE_MAIN_R0 to state STATE_MAIN_R1 Jan  9 22:22:48 fcs01
>> pluto[16053]: "swan" #25: STATE_MAIN_R1: sent MR1, expecting MI2 Jan
>> 9 22:22:48 fcs01 pluto[16053]: "swan" #25: transition from state
>> STATE_MAIN_R1 to state STATE_MAIN_R2 Jan  9 22:22:48 fcs01 pluto[16053]: "swan" #25: STATE_MAIN_R2: sent MR2, expecting MI3 Jan  9 22:22:48 fcs01 pluto[16053]: "swan" #25: Main mode peer ID is ID_IPV4_ADDR: 'xx.xx.56.206'
>> Jan  9 22:22:48 fcs01 pluto[16053]: "swan" #25: transition from state
>> STATE_MAIN_R2 to state STATE_MAIN_R3 Jan  9 22:22:48 fcs01
>> pluto[16053]: "swan" #25: STATE_MAIN_R3: sent MR3, ISAKMP SA
>> established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1536} Jan  9 22:22:48 fcs01 pluto[16053]: "swan" #25: the peer proposed: 10.49.73.0/24:0/0 -> 192.168.72.0/24:0/0 Jan  9 22:22:48 fcs01 pluto[16053]: "swan" #26: responding to Quick Mode proposal {msgid:815f1190}
>> Jan  9 22:22:48 fcs01 pluto[16053]: "swan" #26:     us: 10.49.73.0/24===xx..233.50.68
>> Jan  9 22:22:48 fcs01 pluto[16053]: "swan" #26:   them: xxx.155.56.206<xx.155.56.206>===192.168.72.0/24
>> Jan  9 22:22:48 fcs01 pluto[16053]: "swan" #26: transition from state
>> STATE_QUICK_R0 to state STATE_QUICK_R1 Jan  9 22:22:48 fcs01
>> pluto[16053]: "swan" #26: STATE_QUICK_R1: sent QR1, inbound IPsec SA
>> installed, expecting QI2 Jan  9 22:22:48 fcs01 pluto[16053]: "swan"
>> #26: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2 Jan
>> 9 22:22:48 fcs01 pluto[16053]: "swan" #26: STATE_QUICK_R2: IPsec SA
>> established tunnel mode {ESP=>0xb4f4c8de <0xa17e4de8
>> xfrm=3DES_0-HMAC_SHA1 NATOA=none NATD=none DPD=none}
>> 
>> [root at fcs01 ~]# Jan  9 22:23:10 fcs01 pluto[16053]: "swan" #24:
>> ignoring unknown Vendor ID payload [4f4568794c64414365636661] Jan  9
>> 22:23:10 fcs01 pluto[16053]: "swan" #24: received Vendor ID payload
>> [Dead Peer Detection] Jan  9 22:23:10 fcs01 pluto[16053]: "swan" #24:
>> transition from state STATE_MAIN_I1 to state STATE_MAIN_I2 Jan  9
>> 22:23:10 fcs01 pluto[16053]: "swan" #24: STATE_MAIN_I2: sent MI2,
>> expecting MR2 Jan  9 22:23:10 fcs01 pluto[16053]: "swan" #24:
>> transition from state STATE_MAIN_I2 to state STATE_MAIN_I3 Jan  9 22:23:10 fcs01 pluto[16053]: "swan" #24: STATE_MAIN_I3: sent MI3, expecting MR3 Jan  9 22:23:10 fcs01 pluto[16053]: "swan" #24: received Vendor ID payload [CAN-IKEv2] Jan  9 22:23:10 fcs01 pluto[16053]: "swan" #24: Main mode peer ID is ID_IPV4_ADDR: 'xx.xx.56.206'
>> Jan  9 22:23:10 fcs01 pluto[16053]: "swan" #24: transition from state
>> STATE_MAIN_I3 to state STATE_MAIN_I4 Jan  9 22:23:10 fcs01
>> pluto[16053]: "swan" #24: STATE_MAIN_I4: ISAKMP SA established
>> {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha
>> group=modp1536} Jan  9 22:23:10 fcs01 pluto[16053]: "swan" #27:
>> initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW+SAREFTRACK
>> {using isakmp#24 msgid:dccc3a97 proposal=3DES(3)_192-SHA1(2)_160,
>> DES(2)_064-MD5(1)_128 pfsgroup=OAKLEY_GROUP_MODP1536} Jan  9 22:23:10
>> fcs01 pluto[16053]: "swan" #27: transition from state STATE_QUICK_I1
>> to state STATE_QUICK_I2 Jan  9 22:23:10 fcs01 pluto[16053]: "swan"
>> #27: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode
>> {ESP=>0x6335e9b5 <0xb9337ef3 xfrm=3DES_0-HMAC_SHA1 NATOA=none
>> NATD=none DPD=none}
>> 
>> On Centos62/swan, i see this
>> 
>> Jan  9 22:24:27 centos62 pluto[32740]: "fcs01" #1: ignoring unknown
>> Vendor ID payload [4f4576795c6b677a57715c73] Jan  9 22:24:27 centos62
>> pluto[32740]: "fcs01" #1: received Vendor ID payload [Dead Peer
>> Detection] Jan  9 22:24:27 centos62 pluto[32740]: "fcs01" #1:
>> transition from state STATE_MAIN_I1 to state STATE_MAIN_I2 Jan  9
>> 22:24:27 centos62 pluto[32740]: "fcs01" #1: STATE_MAIN_I2: sent MI2,
>> expecting MR2 Jan  9 22:24:27 centos62 pluto[32740]: "fcs01" #1:
>> transition from state STATE_MAIN_I2 to state STATE_MAIN_I3 Jan  9 22:24:27 centos62 pluto[32740]: "fcs01" #1: STATE_MAIN_I3: sent MI3, expecting MR3 Jan  9 22:24:27 centos62 pluto[32740]: "fcs01" #1: received Vendor ID payload [CAN-IKEv2] Jan  9 22:24:27 centos62 pluto[32740]: "fcs01" #1: Main mode peer ID is ID_IPV4_ADDR: 'xxx.xxx.50.68'
>> Jan  9 22:24:27 centos62 pluto[32740]: "fcs01" #1: transition from
>> state STATE_MAIN_I3 to state STATE_MAIN_I4 Jan  9 22:24:27 centos62
>> pluto[32740]: "fcs01" #1: STATE_MAIN_I4: ISAKMP SA established
>> {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha
>> group=modp1536} Jan  9 22:24:27 centos62 pluto[32740]: "fcs01" #2:
>> initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW+SAREFTRACK
>> {using isakmp#1 msgid:815f1190 proposal=3DES(3)_192-SHA1(2)_160,
>> DES(2)_064-MD5(1)_128 pfsgroup=OAKLEY_GROUP_MODP1536} Jan  9 22:24:27
>> centos62 pluto[32740]: "fcs01" #2: transition from state
>> STATE_QUICK_I1 to state STATE_QUICK_I2 Jan  9 22:24:27 centos62
>> pluto[32740]: "fcs01" #2: STATE_QUICK_I2: sent QI2, IPsec SA
>> established tunnel mode {ESP=>0xa17e4de8 <0xb4f4c8de
>> xfrm=3DES_0-HMAC_SHA1 NATOA=none NATD=none DPD=none}
>> 
>> What do these mean?
>> 
>> Jan  9 22:24:49 centos62 pluto[32740]: packet from xx.xx.50.68:500:
>> ignoring unknown Vendor ID payload [4f4576795c6b677a57715c73] Jan  9
>> 22:24:49 centos62 pluto[32740]: packet from xx.xx.50.68:500: received
>> Vendor ID payload [Dead Peer Detection] Jan  9 22:24:49 centos62
>> pluto[32740]: packet from xx.xx.50.68:500: received Vendor ID payload
>> [RFC 3947] meth=109, but port floating is off Jan  9 22:24:49 centos62
>> pluto[32740]: packet from xx.xx.50.68:500: received Vendor ID payload
>> [draft-ietf-ipsec-nat-t-ike-03] meth=108, but port floating is off Jan
>> 9 22:24:49 centos62 pluto[32740]: packet from xx.xxx.50.68:500:
>> received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106,
>> but port floating is off Jan  9 22:24:49 centos62 pluto[32740]: packet
>> from xx.xx.50.68:500: received Vendor ID payload
>> [draft-ietf-ipsec-nat-t-ike-02] meth=107, but port floating is off Jan
>> 9 22:24:49 centos62 pluto[32740]: packet from xx.xx.50.68:500:
>> ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
>> 
>> Jan  9 22:24:49 centos62 pluto[32740]: "fcs01" #3: responding to Main
>> Mode Jan  9 22:24:49 centos62 pluto[32740]: "fcs01" #3: transition
>> from state STATE_MAIN_R0 to state STATE_MAIN_R1 Jan  9 22:24:49
>> centos62 pluto[32740]: "fcs01" #3: STATE_MAIN_R1: sent MR1, expecting
>> MI2 Jan  9 22:24:49 centos62 pluto[32740]: "fcs01" #3: transition from
>> state STATE_MAIN_R1 to state STATE_MAIN_R2 Jan  9 22:24:49 centos62 pluto[32740]: "fcs01" #3: STATE_MAIN_R2: sent MR2, expecting MI3 Jan  9 22:24:49 centos62 pluto[32740]: "fcs01" #3: Main mode peer ID is ID_IPV4_ADDR: 'xxx.xxx.50.68'
>> Jan  9 22:24:49 centos62 pluto[32740]: "fcs01" #3: transition from
>> state STATE_MAIN_R2 to state STATE_MAIN_R3 Jan  9 22:24:49 centos62
>> pluto[32740]: "fcs01" #3: STATE_MAIN_R3: sent MR3, ISAKMP SA
>> established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1536} Jan  9 22:24:49 centos62 pluto[32740]: "fcs01" #3: the peer proposed: 192.168.72.0/24:0/0 -> 10.49.73.0/24:0/0 Jan  9 22:24:49 centos62 pluto[32740]: "fcs01" #4: responding to Quick Mode proposal {msgid:dccc3a97}
>> Jan  9 22:24:49 centos62 pluto[32740]: "fcs01" #4:     us: 192.168.72.0/24===192.168.72.69[xx.xx.56.206,+S=C]
>> Jan  9 22:24:49 centos62 pluto[32740]: "fcs01" #4:   them: xxx.xxx.50.68<xxx.xxx.50.68>[+S=C]===10.49.73.0/24
>> Jan  9 22:24:49 centos62 pluto[32740]: "fcs01" #4: keeping
>> refhim=4294901761 during rekey Jan  9 22:24:49 centos62 pluto[32740]:
>> "fcs01" #4: transition from state STATE_QUICK_R0 to state
>> STATE_QUICK_R1 Jan  9 22:24:49 centos62 pluto[32740]: "fcs01" #4:
>> STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
>> Jan  9 22:24:49 centos62 pluto[32740]: "fcs01" #4: transition from
>> state STATE_QUICK_R1 to state STATE_QUICK_R2 Jan  9 22:24:49 centos62
>> pluto[32740]: "fcs01" #4: STATE_QUICK_R2: IPsec SA established tunnel
>> mode {ESP=>0xb9337ef3 <0x6335e9b5 xfrm=3DES_0-HMAC_SHA1 NATOA=none
>> NATD=none DPD=none}
>> 
>> 
>> I know the port forwarding is fine on the router as I use net cat
>> pushing the udp ports 500/4500 as i see the net cat probe from i run
>> from fcs01 to the public static ip i have on my home
>> 
>> # tcpdump -lnni  eth0 port 500
>>  tcpdump: verbose output suppressed, use -v or -vv for full protocol
>> decode listening on eth0, link-type EN10MB (Ethernet), capture size
>> 65535 bytes
>> 22:22:31.893797 IP xx.xxx.50.68.51246 > 192.168.72.69.4500: [|isakmp]
>> 22:22:31.893859 IP xx.xxx.50.68.51246 > 192.168.72.69.4500: [|isakmp]
>> 22:22:32.895488 IP xx.xxx.50.68.51246 > 192.168.72.69.4500: [|isakmp]
>> 22:22:33.896155 IP xx.xxx.50.68.51246 > 192.168.72.69.4500: [|isakmp]
>> 22:22:34.897823 IP xx.xxx.50.68.51246 > 192.168.72.69.4500: [|isakmp]
>> 
>> [root at centos62 ~]# tcpdump -lnni  eth0 port 500
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>> decode listening on eth0, link-type EN10MB (Ethernet), capture size
>> 65535 bytes
>> 22:23:19.926083 IP xxx.233.50.68.34727 > 192.168.72.69.500: [|isakmp]
>> 22:23:19.926142 IP xxx.233.50.68.34727 > 192.168.72.69.500: [|isakmp]
>> 22:23:20.926243 IP xxx.233.50.68.34727 > 192.168.72.69.500: [|isakmp]
>> 22:23:21.927177 IP xxx.233.50.68.34727 > 192.168.72.69.500: [|isakmp]
>> 22:23:22.928614 IP xxx.233.50.68.34727 > 192.168.72.69.500: [|isakmp]
>> 
>> The problem Im having is that I cannot ping  192.168.72.69 from fcs01
>> and vica versa,  (like I can with my other connections)
>> 
>> I also don't believe I understand whether I should be using nat-traversal, as I've tried on both sides as I've tried :-/   Also have dropped the firewall rules on both linux hosts and reinitiated the tunnels but nothing changes.
>> 
>> Ive copied the config from one of my other openswan linux hosts and just modified the right hand side IP/networks to accommodate this connection.
>> 
>> I've also been able to terminate an ipsec tunnel from fcs01 on my draytek 2820n  without any issues.
>> 
>> HAs someone come across this config before and point whether they can see a problem.
>> 
>> Configs below
>> 
>> (cents box being draytek @ home )
>> 
>> [root at centos62 ipsec.d]# cat fcs01.conf # basic configuration #config
>> setup
>> #    interfaces=eth0
>> #    nat_traversal=yes
>> #    oe=no
>> #    protostack=netkey
>> #   syslog=syslog.debug
>> 
>> conn fcs01
>>     type=tunnel
>>     connaddrfamily=ipv4
>>     authby=secret
>>     auto=start
>>     #auto=route
>>     compress=no
>>     ike=3des-sha1,des-md5
>>     phase2alg=3des-sha1,des-md5
>>     phase2=esp
>>     ikelifetime=3600s
>>     keyexchange=ike
>>     keylife=28800s
>>     keyingtries=%forever
>>     left=%defaultroute
>>     leftid=xx.xx.56.206
>>     leftsourceip=192.168.72.69
>>     leftsubnet=192.168.72.0/24
>>     pfs=yes
>>     #dpdaction=restart
>>     #dpdtimeout=30
>>     #dpddelay=120
>> 
>>     right=xx.xx.50.68
>>     rightsourceip=10.49.73.1
>>     rightid=xx.xx.50.68
>>     rightsubnet=10.49.73.0/24
>> 
>> [root at fcs01 ipsec.d]# cat swan.conf
>> # basic configuration
>> #config setup
>> #    interfaces=eth0
>> #    oe=no
>> ##    protostack=netkey
>> #    syslog=syslog.debug
>>     virtual_private=%v4:10.49.73.0/24,%v4:192.168.72.0/24
>> 
>> conn swan
>>     type=tunnel
>>     connaddrfamily=ipv4
>>     authby=secret
>>     auto=start
>>     #auto=route
>>     compress=no
>>     ike=3des-sha1,des-md5
>>     phase2alg=3des-sha1,des-md5
>>     phase2=esp
>>     ikelifetime=3600s
>>     keyexchange=ike
>>     keylife=28800s
>>     keyingtries=%forever
>>     left=%defaultroute
>>     leftsourceip=10.49.73.1
>>     leftid=xx.x.50.68
>>     leftsubnet=10.49.73.0/24
>>     pfs=yes
>> #    dpdaction=restart
>>  #   dpdtimeout=30
>>   #  dpddelay=120
>> 
>>     right=xx.xx.56.206
>>     rightid=xx.xx.56.206
>>     rightsourceip=192.168.72.69
>>     rightsubnet=192.168.72.0/24
>> 
>> 
>> Any ideas? Thanks in advance
>> _______________________________________________
>> Users at lists.openswan.org
>> https://lists.openswan.org/mailman/listinfo/users
>> Micropayments:
>> https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
>> Building and Integrating Virtual Private Networks with Openswan:
>> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=2831
>> 55
> 
> _______________________________________________
> Users at lists.openswan.org
> https://lists.openswan.org/mailman/listinfo/users
> Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
> Building and Integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
> 
> --
> This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by Trusted Management Limited, and is
> believed to be clean.
> 

Regards

Dan.



More information about the Users mailing list