Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
VPN Client not connecting [SOLVED]
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5  Next  
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
salahx
Guru
Guru


Joined: 12 Mar 2005
Posts: 530

PostPosted: Mon Sep 29, 2014 12:25 am    Post subject: Reply with quote

Does the whole tunnel disappear or just the session? What does the syslog showing from tunnel creation to destruction?

Lets modify the commands slightly to get more debug output, by adding trace_flags:
Code:

l2tp> tunnel create tunnel_name="VPN.OFFICE.COM"" dest_ipaddr=vpn.office.com  our_udp_port=1701 trace_flags=all
l2tp> session create session_name="VPN.OFFICE.COM" user_name=USER_NAME user_password=USER_PASSWORD tunnel_name="VPN.OFFICE.COM" trace_flags=all


This should result in (probably too much!) debug data being printed out in the syslog. Maybe it might provide a clue of why it keeps disconnecting.
Back to top
View user's profile Send private message
Duco Ergo Sum
Apprentice
Apprentice


Joined: 06 Dec 2005
Posts: 154
Location: Winsford

PostPosted: Mon Sep 29, 2014 7:47 am    Post subject: Reply with quote

Both the tunnel and session disappear. Below is my log.

I know that Windows is able to establish a stable connection. Is there possibly, something going on at the other end which could be causing us issues?

One thing I found in Windows when the connection was up was that I could not view the internet. At the time, I had little interest in debugging Windows as my goal is to have my regular system working. Now, I'm wondering what those issues on Windows are and if or how they're connected... These did not seem related when we started as then we weren't even able to get a connection.

Code:

Sep 29 08:06:37 sveta charon: 04[CFG] received stroke: initiate 'VPN.OFFICE.COM'
Sep 29 08:06:37 sveta charon: 06[IKE] initiating Main Mode IKE_SA VPN.OFFICE.COM[1] to 17.11.7.5
Sep 29 08:06:37 sveta charon: 06[IKE] initiating Main Mode IKE_SA VPN.OFFICE.COM[1] to 17.11.7.5
Sep 29 08:06:37 sveta charon: 06[ENC] generating ID_PROT request 0 [ SA V V V V ]
Sep 29 08:06:37 sveta charon: 06[NET] sending packet: from 1.2.3.4[500] to 17.11.7.5[500] (184 bytes)
Sep 29 08:06:37 sveta charon: 05[NET] received packet: from 17.11.7.5[500] to 1.2.3.4[500] (116 bytes)
Sep 29 08:06:37 sveta charon: 05[ENC] parsed ID_PROT response 0 [ SA V V ]
Sep 29 08:06:37 sveta charon: 05[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Sep 29 08:06:37 sveta charon: 05[IKE] received FRAGMENTATION vendor ID
Sep 29 08:06:37 sveta charon: 05[ENC] generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
Sep 29 08:06:37 sveta charon: 05[NET] sending packet: from 1.2.3.4[500] to 17.11.7.5[500] (244 bytes)
Sep 29 08:06:38 sveta charon: 07[NET] received packet: from 17.11.7.5[500] to 1.2.3.4[500] (304 bytes)
Sep 29 08:06:38 sveta charon: 07[ENC] parsed ID_PROT response 0 [ KE No V V V V NAT-D NAT-D ]
Sep 29 08:06:38 sveta charon: 07[IKE] received Cisco Unity vendor ID
Sep 29 08:06:38 sveta charon: 07[IKE] received XAuth vendor ID
Sep 29 08:06:38 sveta charon: 07[ENC] received unknown vendor ID: [HIDDEN]
Sep 29 08:06:38 sveta charon: 07[ENC] received unknown vendor ID: [HIDDEN]
Sep 29 08:06:38 sveta charon: 07[IKE] local host is behind NAT, sending keep alives
Sep 29 08:06:38 sveta charon: 07[ENC] generating ID_PROT request 0 [ ID HASH ]
Sep 29 08:06:38 sveta charon: 07[NET] sending packet: from 1.2.3.4[4500] to 17.11.7.5[4500] (68 bytes)
Sep 29 08:06:38 sveta charon: 08[NET] received packet: from 17.11.7.5[4500] to 1.2.3.4[4500] (84 bytes)
Sep 29 08:06:38 sveta charon: 08[ENC] parsed ID_PROT response 0 [ ID HASH V ]
Sep 29 08:06:38 sveta charon: 08[IKE] received DPD vendor ID
Sep 29 08:06:38 sveta charon: 08[IKE] IKE_SA VPN.OFFICE.COM[1] established between 1.2.3.4[1.2.3.4]...17.11.7.5[17.11.7.5]
Sep 29 08:06:38 sveta charon: 08[IKE] IKE_SA VPN.OFFICE.COM[1] established between 1.2.3.4[1.2.3.4]...17.11.7.5[17.11.7.5]
Sep 29 08:06:38 sveta charon: 08[ENC] generating QUICK_MODE request [HIDDEN] [ HASH SA No ID ID NAT-OA NAT-OA ]
Sep 29 08:06:38 sveta charon: 08[NET] sending packet: from 1.2.3.4[4500] to 17.11.7.5[4500] (220 bytes)
Sep 29 08:06:38 sveta charon: 09[NET] received packet: from 17.11.7.5[4500] to 1.2.3.4[4500] (180 bytes)
Sep 29 08:06:38 sveta charon: 09[ENC] parsed QUICK_MODE response [HIDDEN] [ HASH SA No ID ID N((24576)) NAT-OA ]
Sep 29 08:06:38 sveta charon: 09[IKE] received 28800s lifetime, configured 0s
Sep 29 08:06:38 sveta charon: 09[IKE] CHILD_SA VPN.OFFICE.COM{1} established with SPIs cadd4ef9_i 96a01b83_o and TS 1.2.3.4/32[udp/l2tp] === 17.11.7.5/32[udp/l2tp]
Sep 29 08:06:38 sveta charon: 09[IKE] CHILD_SA VPN.OFFICE.COM{1} established with SPIs cadd4ef9_i 96a01b83_o and TS 1.2.3.4/32[udp/l2tp] === 17.11.7.5/32[udp/l2tp]
Sep 29 08:06:38 sveta charon: 09[ENC] generating QUICK_MODE request [HIDDEN] [ HASH ]
Sep 29 08:06:38 sveta charon: 09[NET] sending packet: from 1.2.3.4[4500] to 17.11.7.5[4500] (60 bytes)
Sep 29 08:07:02 sveta charon: 08[IKE] sending keep alive to 17.11.7.5[4500]
Sep 29 08:07:09 sveta openl2tpd[3726]: FSM: CCE(6362) event OPEN_REQ in state IDLE
Sep 29 08:07:09 sveta openl2tpd[3726]: PROTO: tunl 6362: sending SCCRQ
Sep 29 08:07:09 sveta openl2tpd[3726]: FSM: CCE(6362) state change: IDLE --> WAITCTLREPLY
Sep 29 08:07:09 sveta openl2tpd[3726]: FUNC: tunl 6362 created
Sep 29 08:07:09 sveta openl2tpd[3726]: PROTO: tunl 6362: SCCRP received from peer 7993
Sep 29 08:07:09 sveta openl2tpd[3726]: FSM: CCE(6362) event SCCRP_ACCEPT in state WAITCTLREPLY
Sep 29 08:07:09 sveta openl2tpd[3726]: PROTO: tunl 6362: sending SCCCN to peer 7993
Sep 29 08:07:09 sveta openl2tpd[3726]: FUNC: tunl 6362 up
Sep 29 08:07:09 sveta openl2tpd[3726]: FSM: CCE(6362) state change: WAITCTLREPLY --> ESTABLISHED
Sep 29 08:07:23 sveta openl2tpd[3726]: FSM: LAIC(6362/22446) event INCALL_IND in state IDLE
Sep 29 08:07:23 sveta openl2tpd[3726]: FSM: LAIC(6362/22446) state change: IDLE --> WAITTUNNEL
Sep 29 08:07:23 sveta openl2tpd[3726]: 6362/22446: creating UNIX pppd context
Sep 29 08:07:23 sveta openl2tpd[3726]: 6362/22446: using ppp profile 'default'
Sep 29 08:07:23 sveta openl2tpd[3726]: FSM: LAIC(6362/22446) event TUNNEL_OPEN_IND in state WAITTUNNEL
Sep 29 08:07:23 sveta openl2tpd[3726]: PROTO: tunl 6362/22446: sending ICRQ to peer 7993/0
Sep 29 08:07:23 sveta openl2tpd[3726]: FSM: LAIC(6362/22446) state change: WAITTUNNEL --> WAITREPLY
Sep 29 08:07:23 sveta openl2tpd[3726]: PROTO: tunl 6362/22446: ICRP received from peer 7993
Sep 29 08:07:23 sveta openl2tpd[3726]: FSM: LAIC(6362/22446) event ICRP_ACCEPT in state WAITREPLY
Sep 29 08:07:23 sveta openl2tpd[3726]: PROTO: tunl 6362/22446: sending ICCN to peer 7993/7866
Sep 29 08:07:23 sveta openl2tpd[3726]: 6362/22446: starting UNIX pppd
Sep 29 08:07:23 sveta openl2tpd[3726]: FSM: LAIC(6362/22446) state change: WAITREPLY --> ESTABLISHED
Sep 29 08:07:23 sveta pppd[4137]: Plugin pppol2tp.so loaded.
Sep 29 08:07:23 sveta pppd[4137]: Plugin openl2tp.so loaded.
Sep 29 08:07:23 sveta pppd[4137]: pppd 2.4.7 started by root, uid 0
Sep 29 08:07:23 sveta pppd[4137]: Using interface ppp0
Sep 29 08:07:23 sveta pppd[4137]: Connect: ppp0 <-->
Sep 29 08:07:23 sveta kernel: [  224.927652] l2tp_ppp: sess 6362/22446: set debug=f
Sep 29 08:07:23 sveta kernel: [  224.927655] l2tp_ppp: sess 6362/22446: set mru=1500
Sep 29 08:07:23 sveta kernel: [  224.927665] 00000000: 00 02 1f 39 1e ba ff 03 c0 21 01 01 00 10 02 06  ...9.....!......
Sep 29 08:07:23 sveta kernel: [  224.927667] 00000010: 00 00 00 00 05 06 8c 1a 27 5e                    ........'^
Sep 29 08:07:23 sveta NetworkManager[2660]: <warn> /sys/devices/virtual/net/ppp0: couldn't determine device driver; ignoring...
Sep 29 08:07:23 sveta openl2tpd[3726]: PROTO: tunl 6362/22446: SLI received from peer 7993
Sep 29 08:07:23 sveta kernel: [  224.952793] 00000000: 00 02 1f 39 1e ba ff 03 c0 21 02 01 00 0f 03 05  ...9.....!......
Sep 29 08:07:23 sveta kernel: [  224.952795] 00000010: c2 23 81 05 06 44 4e a7 b6                       .#...DN..
Sep 29 08:07:23 sveta kernel: [  224.952971] 00000000: 00 02 1f 39 1e ba ff 03 c0 21 01 02 00 0a 05 06  ...9.....!......
Sep 29 08:07:23 sveta kernel: [  224.952975] 00000010: 8c 1a 27 5e                                      ..'^
Sep 29 08:07:23 sveta kernel: [  224.979713] l2tp_ppp: sess 6362/22446: set debug=f
Sep 29 08:07:23 sveta kernel: [  224.979716] l2tp_ppp: sess 6362/22446: set mru=1500
Sep 29 08:07:23 sveta kernel: [  224.980508] 00000000: 00 02 1f 39 1e ba ff 03 c2 23 02 01 00 3d 31 3c  ...9.....#...=1<
Sep 29 08:07:23 sveta kernel: [  224.980510] 00000010: b4 c6 92 21 ce 6f eb 5c cf 66 7c 5e 2b 9f 88 00  ...!.o.\.f|^+...
Sep 29 08:07:29 sveta charon: 10[IKE] sending keep alive to 17.11.7.5[4500]
Sep 29 08:07:29 sveta kernel: [  230.826791] l2tp_ppp: sess 6362/22446: get L2TP stats
Sep 29 08:07:34 sveta pppd[4137]: CHAP authentication succeeded
Sep 29 08:07:34 sveta kernel: [  235.594832] 00000000: 00 02 1f 39 1e ba ff 03 80 21 01 01 00 0a 03 06  ...9.....!......
Sep 29 08:07:34 sveta kernel: [  235.594835] 00000010: 00 00 00 00                                      ....
Sep 29 08:07:37 sveta kernel: [  238.594062] 00000000: 00 02 1f 39 1e ba ff 03 80 21 01 01 00 0a 03 06  ...9.....!......
Sep 29 08:07:37 sveta kernel: [  238.594067] 00000010: 00 00 00 00                                      ....
Sep 29 08:07:37 sveta kernel: [  238.620743] 00000000: 00 02 1f 39 1e ba ff 03 80 21 02 01 00 0a 03 06  ...9.....!......
Sep 29 08:07:37 sveta kernel: [  238.620745] 00000010: 5b 67 aa 85                                      [g..
Sep 29 08:07:37 sveta kernel: [  238.621115] 00000000: 00 02 1f 39 1e ba ff 03 80 21 01 02 00 0a 03 06  ...9.....!......
Sep 29 08:07:37 sveta kernel: [  238.621117] 00000010: ac 12 07 10                                      ....
Sep 29 08:07:37 sveta charon: 12[KNL] 125.64.27.8 appeared on ppp0
Sep 29 08:07:37 sveta pppd[4137]: local  IP address 125.64.27.8
Sep 29 08:07:37 sveta pppd[4137]: remote IP address 17.11.7.5
Sep 29 08:07:37 sveta openl2tpd[3726]: FUNC: tunl 6362/22446: using interface ppp0
Sep 29 08:07:37 sveta charon: 14[KNL] 125.64.27.8 disappeared from ppp0
Sep 29 08:07:37 sveta charon: 06[KNL] 125.64.27.8 appeared on ppp0
Sep 29 08:07:37 sveta charon: 07[KNL] interface ppp0 activated
Sep 29 08:07:49 sveta charon: 12[IKE] sending keep alive to 17.11.7.5[4500]
Sep 29 08:07:49 sveta kernel: [  249.990866] 00000000: 00 02 1f 39 1e ba ff 03 00 21 45 00 00 1d 94 77  ...9.....!E....w
Sep 29 08:07:49 sveta kernel: [  249.990869] 00000010: 40 00 40 11 95 67 0a 01 01 04 5b 67 aa 85 11 94  @.@..g....[g....
Sep 29 08:07:49 sveta kernel: [  249.991271] 00000000: 00 02 1f 39 1e ba ff 03 00 21 45 00 04 30 94 84  ...9.....!E..0..
Sep 29 08:07:49 sveta kernel: [  249.991273] 00000010: 00 00 40 11 d1 47 0a 01 01 04 5b 67 aa 85 11 94  ..@..G....[g....
Sep 29 08:08:09 sveta charon: 13[IKE] sending keep alive to 17.11.7.5[4500]
Sep 29 08:08:09 sveta kernel: [  269.971063] 00000000: 00 02 1f 39 1e ba ff 03 00 21 45 00 00 1d 94 86  ...9.....!E.....
Sep 29 08:08:09 sveta kernel: [  269.971066] 00000010: 40 00 40 11 95 58 0a 01 01 04 5b 67 aa 85 11 94  @.@..X....[g....
Sep 29 08:08:09 sveta kernel: [  269.971411] 00000010: 00 00 40 11 d1 89 0a 01 01 04 5b 67 aa 85 11 94  ..@.......[g....
Sep 29 08:08:09 sveta kernel: [  269.971470] 00000000: 00 02 1f 39 1e ba ff 03 00 21 45 00 04 30 94 93  ...9.....!E..0..
Sep 29 08:08:09 sveta kernel: [  269.971471] 00000010: 00 00 40 11 d1 38 0a 01 01 04 5b 67 aa 85 11 94  ..@..8....[g....
Sep 29 08:08:29 sveta charon: 06[IKE] sending keep alive to 17.11.7.5[4500]
Sep 29 08:08:29 sveta kernel: [  289.951275] 00000000: 00 02 1f 39 1e ba ff 03 00 21 45 00 00 1d 94 95  ...9.....!E.....
Sep 29 08:08:29 sveta kernel: [  289.951278] 00000010: 40 00 40 11 95 49 0a 01 01 04 5b 67 aa 85 11 94  @.@..I....[g....
Sep 29 08:08:29 sveta kernel: [  289.951683] 00000010: 00 00 40 11 d1 7a 0a 01 01 04 5b 67 aa 85 11 94  ..@..z....[g....
Sep 29 08:08:29 sveta kernel: [  289.951740] 00000000: 00 02 1f 39 1e ba ff 03 00 21 45 00 04 30 94 a2  ...9.....!E..0..
Sep 29 08:08:29 sveta kernel: [  289.951742] 00000010: 00 00 40 11 d1 29 0a 01 01 04 5b 67 aa 85 11 94  ..@..)....[g....
Sep 29 08:08:49 sveta charon: 07[IKE] sending keep alive to 17.11.7.5[4500]
Sep 29 08:08:49 sveta kernel: [  309.931513] 00000000: 00 02 1f 39 1e ba ff 03 00 21 45 00 00 1d 94 a4  ...9.....!E.....
Sep 29 08:08:49 sveta kernel: [  309.931907] 00000000: 00 02 1f 39 1e ba ff 03 00 21 45 00 04 30 94 b1  ...9.....!E..0..
Sep 29 08:08:49 sveta kernel: [  309.931908] 00000010: 00 00 40 11 d1 1a 0a 01 01 04 5b 67 aa 85 11 94  ..@.......[g....
Sep 29 08:09:09 sveta charon: 08[IKE] sending keep alive to 17.11.7.5[4500]
Sep 29 08:09:09 sveta kernel: [  329.911759] 00000000: 00 02 1f 39 1e ba ff 03 00 21 45 00 00 1d 94 b3  ...9.....!E.....
Sep 29 08:09:09 sveta kernel: [  329.912173] 00000000: 00 02 1f 39 1e ba ff 03 00 21 45 00 04 30 94 c0  ...9.....!E..0..
Sep 29 08:09:09 sveta kernel: [  329.912174] 00000010: 00 00 40 11 d1 0b 0a 01 01 04 5b 67 aa 85 11 94  ..@.......[g....
Sep 29 08:09:24 sveta openl2tpd[3726]: PROTO: tunl 6362: sending HELLO
Sep 29 08:09:24 sveta kernel: [  345.407261] 00000000: 00 02 1f 39 1e ba ff 03 00 21 45 00 00 58 94 c2  ...9.....!E..X..
Sep 29 08:09:24 sveta kernel: [  345.407264] 00000010: 40 00 40 11 94 e1 0a 01 01 04 5b 67 aa 85 11 94  @.@.......[g....
Sep 29 08:09:28 sveta kernel: [  349.153895] 00000000: 00 02 1f 39 1e ba ff 03 00 21 45 00 04 68 94 ed  ...9.....!E..h..
Sep 29 08:09:28 sveta kernel: [  349.153896] 00000010: 00 00 40 11 d0 a6 0a 01 01 04 5b 67 aa 85 11 94  ..@.......[g....
Sep 29 08:09:29 sveta charon: 04[IKE] sending keep alive to 17.11.7.5[4500]
Sep 29 08:09:29 sveta kernel: [  349.891975] 00000000: 00 02 1f 39 1e ba ff 03 00 21 45 00 00 1d 94 ef  ...9.....!E.....
Sep 29 08:09:29 sveta kernel: [  349.891978] 00000010: 40 00 40 11 94 ef 0a 01 01 04 5b 67 aa 85 11 94  @.@.......[g....
Sep 29 08:09:32 sveta kernel: [  352.900150] 00000000: 00 02 1f 39 1e ba ff 03 00 21 45 00 04 68 95 29  ...9.....!E..h.)
Sep 29 08:09:32 sveta kernel: [  352.900151] 00000010: 00 00 40 11 d0 6a 0a 01 01 04 5b 67 aa 85 11 94  ..@..j....[g....
Sep 29 08:09:33 sveta openl2tpd[3726]: FSM: CCE(6362) event XPRT_DOWN in state ESTABLISHED
Sep 29 08:09:33 sveta openl2tpd[3726]: PROTO: tunl 6362: sending STOPCCN to peer 7993
Sep 29 08:09:33 sveta openl2tpd[3726]: FUNC: tunl 6362 down
Sep 29 08:09:33 sveta openl2tpd[3726]: FSM: CCE(6362) state change: ESTABLISHED --> CLOSING
Sep 29 08:09:33 sveta openl2tpd[3726]: FSM: LAIC(6362/22446) event CLOSE_REQ in state ESTABLISHED
Sep 29 08:09:33 sveta openl2tpd[3726]: PROTO: tunl 6362/22446: sending CDN to peer 7993/7866
Sep 29 08:09:33 sveta openl2tpd[3726]: 6362/22446: stopping unix pppd pid 4137
Sep 29 08:09:33 sveta openl2tpd[3726]: 6362/22446: cleaning UNIX pppd context
Sep 29 08:09:33 sveta openl2tpd[3726]: FSM: LAIC(6362/22446) state change: ESTABLISHED --> IDLE
Sep 29 08:09:33 sveta pppd[4137]: Terminating on signal 15
Sep 29 08:09:33 sveta pppd[4137]: Connect time 2.0 minutes.
Sep 29 08:09:33 sveta pppd[4137]: Sent 111582 bytes, received 0 bytes.
Sep 29 08:09:33 sveta charon: 10[KNL] interface ppp0 deactivated
Sep 29 08:09:33 sveta charon: 09[KNL] 125.64.27.8 disappeared from ppp0
Sep 29 08:09:33 sveta kernel: [  354.149007] l2tp_ppp: sess 6362/22446: set debug=f
Sep 29 08:09:33 sveta kernel: [  354.149010] l2tp_ppp: sess 6362/22446: set mru=1500
Sep 29 08:09:33 sveta kernel: [  354.149017] 00000000: 00 02 1f 39 1e ba ff 03 c0 21 05 03 00 10 55 73  ...9.....!....Us
Sep 29 08:09:33 sveta kernel: [  354.149018] 00000010: 65 72 20 72 65 71 75 65 73 74                    er request
Sep 29 08:09:34 sveta openl2tpd[3726]: FSM: CCE(6362) event XPRT_DOWN in state CLOSING
Sep 29 08:09:36 sveta kernel: [  357.149089] 00000000: 00 02 1f 39 1e ba ff 03 c0 21 05 04 00 10 55 73  ...9.....!....Us
Sep 29 08:09:36 sveta kernel: [  357.149092] 00000010: 65 72 20 72 65 71 75 65 73 74                    er request
Sep 29 08:09:39 sveta pppd[4137]: Connection terminated.
Sep 29 08:09:39 sveta avahi-daemon[2987]: Withdrawing workstation service for ppp0.
Sep 29 08:09:39 sveta charon: 15[KNL] interface ppp0 deleted
Sep 29 08:09:39 sveta pppd[4137]: Modem hangup
Sep 29 08:09:39 sveta pppd[4137]: Exit.
Sep 29 08:09:53 sveta charon: 08[IKE] sending keep alive to 17.11.7.5[4500]
Sep 29 08:10:01 sveta cron[4182]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons)
Sep 29 08:10:13 sveta charon: 04[IKE] sending keep alive to 17.11.7.5[4500]
Sep 29 08:10:33 sveta charon: 10[IKE] sending keep alive to 17.11.7.5[4500]
Sep 29 08:10:33 sveta openl2tpd[3726]: FUNC: tunl 6362 deleted
Sep 29 08:10:33 sveta openl2tpd[3726]: FUNC: tunl 6362: deleting context
Sep 29 08:10:53 sveta charon: 13[IKE] sending keep alive to 17.11.7.5[4500]
Sep 29 08:11:13 sveta charon: 12[IKE] sending keep alive to 17.11.7.5[4500]
Sep 29 08:11:33 sveta charon: 14[IKE] sending keep alive to 17.11.7.5[4500]
Sep 29 08:11:53 sveta charon: 05[IKE] sending keep alive to 17.11.7.5[4500]
Sep 29 08:12:13 sveta charon: 06[IKE] sending keep alive to 17.11.7.5[4500]
Sep 29 08:12:33 sveta charon: 04[IKE] sending keep alive to 17.11.7.5[4500]
Sep 29 08:12:53 sveta charon: 10[IKE] sending keep alive to 17.11.7.5[4500]
Sep 29 08:13:13 sveta charon: 11[IKE] sending keep alive to 17.11.7.5[4500]
Sep 29 08:13:33 sveta charon: 12[IKE] sending keep alive to 17.11.7.5[4500]
Sep 29 08:13:53 sveta charon: 14[IKE] sending keep alive to 17.11.7.5[4500]


The lesser pruned log.
http://pastebin.com/DbfsLjBV
Back to top
View user's profile Send private message
Duco Ergo Sum
Apprentice
Apprentice


Joined: 06 Dec 2005
Posts: 154
Location: Winsford

PostPosted: Mon Sep 29, 2014 8:19 am    Post subject: Reply with quote

I have tried to ping my work PC from windows without success. The only discernible difference is that the connection appears to remain up until I tell it to disconnect. Would this suggest that the problem may lie at the other end? Or maybe I've managed to screw up two connections.
Back to top
View user's profile Send private message
salahx
Guru
Guru


Joined: 12 Mar 2005
Posts: 530

PostPosted: Mon Sep 29, 2014 6:27 pm    Post subject: Reply with quote

I suspect both are suffereing from the same problem. From the logs, it appears we send a L2TP HELLO message to the other end, get no response, so openl2tp figures the other side vanished and shuts down the connection. I don't know how complete Microsoft's L2TP implentation is, perhaps it never realizes the other side becomes inaccessible so connection says up, but its useless.

I figure we must be doing everything right, something else is getting in the way. Either the problem is at the other end or something is getting in the way - I've seen some routers have broken NAT implementions (my old D-link DIR-615), or mangle ipsec packets (a Zyxel P-330W)
Back to top
View user's profile Send private message
Duco Ergo Sum
Apprentice
Apprentice


Joined: 06 Dec 2005
Posts: 154
Location: Winsford

PostPosted: Tue Sep 30, 2014 8:46 am    Post subject: Reply with quote

This makes more sense now.

Code:

 # tracepath 3.5.8.13
 1?: [LOCALHOST]                                         pmtu 1500
 1:  fritz.box                                             0.749ms
 1:  fritz.box                                             0.656ms
 2:  no reply
 3:  no reply
^C
 # traceroute 3.5.8.13
traceroute to 3.5.8.13 (3.5.8.13), 30 hops max, 60 byte packets
 1  fritz.box (10.1.1.253)  0.650 ms  0.705 ms  0.784 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
Back to top
View user's profile Send private message
salahx
Guru
Guru


Joined: 12 Mar 2005
Posts: 530

PostPosted: Tue Sep 30, 2014 9:21 pm    Post subject: Reply with quote

Actually it DOES make sense. If we go back to the routing table earlier, the default route will be applied for 3.5.8.13/8 (of whatever the prefix length is) and the data won;t go over the tunnel. We would need to manually add route, or use a full tunnel. If the other end doesn't push a route, that would explain why neither Windows nor Linux can connect.

Now according to documentation, Windows by default create a full tunnel (The is controled via [VPN Connection X]->Properties->Networking->General->Advanced->"Use default gateway on remote network", whereas Linux creates a split tunnel.

Its possible to do full tunneling using openl2tp too:
Code:

l2tp> tunnel create tunnel_name="test" ...
l2tp> ppp profile create profile_name="test" default_route=yes
l2tp> session create session create ppp_profile_name="test"  user_name="USERNAME"  user_password="PASSWORD"


But it doesn't work:
Code:

not replacing existing default route to....


We can, however, create routes manually. After connecting, create the route the server behind the vpn by hand:
Code:

# ip route add 3.0.0.0/8 dev ppp0


The try "ping", "tracepath", and "traceroute" and it should go through the VPN. Adjust the networks and masks as needed. IF there multiple network on the other side, you may need multiple "ip route" entries.
Back to top
View user's profile Send private message
Duco Ergo Sum
Apprentice
Apprentice


Joined: 06 Dec 2005
Posts: 154
Location: Winsford

PostPosted: Tue Sep 30, 2014 11:52 pm    Post subject: Reply with quote

I have tried various routing options below none have helped.

Code:

# ifconfig
bond0: flags=5123<UP,BROADCAST,MASTER,MULTICAST>  mtu 1500
        ether [HIDDEN]  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 1.2.3.4  netmask 255.255.255.0  broadcast 10.1.1.255
        inet6 [HIDDEN]  prefixlen 64  scopeid 0x20<link>
        ether [HIDDEN]  txqueuelen 1000  (Ethernet)
        RX packets 15932  bytes 18370533 (17.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 11707  bytes 1517025 (1.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 20  memory [HIDDEN] 

enp59s0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether c8:60:00:cc:49:fc  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 19  memory [HIDDEN] 

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 53  bytes 18645 (18.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 53  bytes 18645 (18.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 125.64.27.8  netmask 255.255.255.255  destination 17.11.7.5                                                         
        ppp  txqueuelen 3  (Point-to-Point Protocol)                                                                                 
        RX packets 4  bytes 34 (34.0 B)                                                                                               
        RX errors 0  dropped 0  overruns 0  frame 0                                                                                   
        TX packets 34  bytes 17794 (17.3 KiB)                                                                                         
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

# ip route list                                                                                                         
default via 10.1.1.253 dev eno1  proto static
default via 10.1.1.253 dev eno1  metric 7
10.1.1.0/24 dev eno1  proto kernel  scope link  src 1.2.3.4  metric 1
17.11.7.5 dev ppp0  proto kernel  scope link  src 125.64.27.8
127.0.0.0/8 dev lo  scope host


# ping -I ppp0 1.3.3.1
PING 1.3.3.1 (1.3.3.1) from 125.64.27.8 ppp0: 56(84) bytes of data.
^C
--- 1.3.3.1 ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 7999ms

# ping -I ppp0 3.5.8.13
PING 3.5.8.13 (3.5.8.13) from 125.64.27.8 ppp0: 56(84) bytes of data.
^C
--- 3.5.8.13 ping statistics ---
13 packets transmitted, 0 received, 100% packet loss, time 12000ms

# ip route add 3.5.8.0/24 via 17.11.7.5
sveta huoshe # ping 3.5.8.13
PING 13.5.8.13 (3.5.8.13) 56(84) bytes of data.
^C
--- 3.5.8.13 ping statistics ---
11 packets transmitted, 0 received, 100% packet loss, time 9999ms
Back to top
View user's profile Send private message
salahx
Guru
Guru


Joined: 12 Mar 2005
Posts: 530

PostPosted: Wed Oct 01, 2014 1:51 am    Post subject: Reply with quote

What does tracepath / traceroute show? It shouldn't show your router, instead the next "hop" should be the VPN gateway (17.11.7.5). IF it DOES show your router, then either we did something wrong somewhere or the router is getting in the way. Is the RX packet counter (ip -s link show ppp0 ) increasing? IF possible, do a "tcpdump -i ppp0" to see if data is going through the tunnel. THe tracepath /tracerotue shoudl give up a clie as to where the routing issues lies.

Don't forget when the interface goes down, all the routing rules associated with it get deleted. Thus have they have recreated every time.
Back to top
View user's profile Send private message
Duco Ergo Sum
Apprentice
Apprentice


Joined: 06 Dec 2005
Posts: 154
Location: Winsford

PostPosted: Wed Oct 01, 2014 8:56 am    Post subject: Reply with quote

Hi.

I have confirmed last night that my brother has no issues accessing his office's VPN. This rules out (I hope) our router and ISP.

I have also attempted to make this connection with a Win-7 laptop and it was much the same as Win-8.1

Below are my latest results.

Code:

ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 125.64.27.8  netmask 255.255.255.255  destination 17.11.7.5
        ppp  txqueuelen 3  (Point-to-Point Protocol)
        RX packets 4  bytes 34 (34.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4  bytes 40 (40.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

sveta huoshe # ip route add 3.5.8.0/24 via 17.11.7.5
sveta huoshe # traceroute 3.5.8.13
traceroute to 3.5.8.13 (3.5.8.13), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

# tracepath 3.5.8.13
 1?: [LOCALHOST]                                         pmtu 1500
 1:  fritz.box                                             0.791ms
 1:  fritz.box                                             0.694ms
 2:  no reply
^C
sveta huoshe # ip route add 3.5.8.0/24 via 17.11.7.5
sveta huoshe # tracepath 3.5.8.13
 1?: [LOCALHOST]                                         pmtu 1500
 1:  no reply
 2:  no reply
^C
sveta huoshe # tcpdump -i ppp0
error : ret -1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
09:29:00.969298 IP sveta.home.org.ipsec-nat-t > 17-11-7-5.no-dns-yet.some.domain.com.ipsec-nat-t: UDP-encap: ESP(spi=[HIDDEN],seq=[HIDDEN]f5c), length 1472
09:29:00.969362 IP sveta.home.org.ipsec-nat-t > 17-11-7-5.no-dns-yet.some.domain.com.ipsec-nat-t: UDP-encap: ESP(spi=[HIDDEN],seq=[HIDDEN]f5d), length 1472
09:29:00.969427 IP sveta.home.org.ipsec-nat-t > 17-11-7-5.no-dns-yet.some.domain.com.ipsec-nat-t: UDP-encap: ESP(spi=[HIDDEN],seq=[HIDDEN]f5e), length 1472
09:29:00.969491 IP sveta.home.org.ipsec-nat-t > 17-11-7-5.no-dns-yet.some.domain.com.ipsec-nat-t: UDP-encap: ESP(spi=[HIDDEN],seq=[HIDDEN]f5f), length 1472
09:29:00.969555 IP sveta.home.org.ipsec-nat-t > 17-11-7-5.no-dns-yet.some.domain.com.ipsec-nat-t: UDP-encap: ESP(spi=[HIDDEN],seq=[HIDDEN]f60), length 1472
09:29:00.969619 IP sveta.home.org.ipsec-nat-t > 17-11-7-5.no-dns-yet.some.domain.com.ipsec-nat-t: UDP-encap: ESP(spi=[HIDDEN],seq=[HIDDEN]f61), length 1472

# ping 3.5.8.13
PING 3.5.8.13 (3.5.8.13) 56(84) bytes of data.
^C
--- 3.5.8.13 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 5999ms

sveta huoshe # ifconfig
bond0: flags=5123<UP,BROADCAST,MASTER,MULTICAST>  mtu 1500
        ether [HIDDEN]  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.1.1.4  netmask 255.255.255.0  broadcast 10.1.1.255
        inet6 [HIDDEN]  prefixlen 64  scopeid 0x20<link>
        ether c8:60:00:cc:46:14  txqueuelen 1000  (Ethernet)
        RX packets 35473  bytes 37930082 (36.1 MiB)
        RX errors 0  dropped 6  overruns 0  frame 0
        TX packets 20150  bytes 2394850 (2.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 20  memory [HIDDEN] 

enp59s0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether c8:60:00:cc:49:fc  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 19  memory [HIDDEN] 

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 79  bytes 22245 (21.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 79  bytes 22245 (21.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 125.64.27.8  netmask 255.255.255.255  destination 17.11.7.5
        ppp  txqueuelen 3  (Point-to-Point Protocol)
        RX packets 4  bytes 34 (34.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 718050  bytes 918718343 (876.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
Back to top
View user's profile Send private message
salahx
Guru
Guru


Joined: 12 Mar 2005
Posts: 530

PostPosted: Wed Oct 01, 2014 3:55 pm    Post subject: Reply with quote

Hmm, that tcpdump isn't right at all. We shouldn't see ipsec ESP packets going over ppp0, only over eno1. Unless this was a copy/paste error and its the wrong interface. If it really from eno1, then that what's were expecting and it means the route is working and the data is going to through the VPN, but the problem is the other side doesn't respond.
Back to top
View user's profile Send private message
Duco Ergo Sum
Apprentice
Apprentice


Joined: 06 Dec 2005
Posts: 154
Location: Winsford

PostPosted: Wed Oct 01, 2014 11:28 pm    Post subject: Reply with quote

I have just re-tested and that post is correct. IPsec going over the ppp0 interface.

Code:
# tcpdump -vvi ppp0
error : ret -1
tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
00:24:18.414826 IP (tos 0x0, ttl 64, id 47411, offset 0, flags [DF], proto UDP (17), length 29)
    sveta.home.org.ipsec-nat-t > 17-11-7-5.no-dns-yet.some.domain.com.ipsec-nat-t: [udp sum ok] isakmp-nat-keep-alive
00:24:18.414861 IP (tos 0x0, ttl 64, id 47412, offset 0, flags [none], proto UDP (17), length 112)
    sveta.home.org.ipsec-nat-t > 17-11-7-5.no-dns-yet.some.domain.com.ipsec-nat-t: [no cksum] UDP-encap: ESP(spi=[HIDDEN],seq=0x47), length 84
00:24:18.414873 IP (tos 0x0, ttl 64, id 47413, offset 0, flags [none], proto UDP (17), length 192)
    sveta.home.org.ipsec-nat-t > 17-11-7-5.no-dns-yet.some.domain.com.ipsec-nat-t: [no cksum] UDP-encap: ESP(spi=[HIDDEN],seq=0x48), length 164
00:24:18.414887 IP (tos 0x0, ttl 64, id 47414, offset 0, flags [none], proto UDP (17), length 272)
    sveta.home.org.ipsec-nat-t > 17-11-7-5.no-dns-yet.some.domain.com.ipsec-nat-t: [no cksum] UDP-encap: ESP(spi=[HIDDEN],seq=0x49), length 244
00:24:18.414904 IP (tos 0x0, ttl 64, id 47415, offset 0, flags [none], proto UDP (17), length 352)
    sveta.home.org.ipsec-nat-t > 17-11-7-5.no-dns-yet.some.domain.com.ipsec-nat-t: [no cksum] UDP-encap: ESP(spi=[HIDDEN],seq=0x4a), length 324
00:24:18.414925 IP (tos 0x0, ttl 64, id 47416, offset 0, flags [none], proto UDP (17), length 432)
    sveta.home.org.ipsec-nat-t > 17-11-7-5.no-dns-yet.some.domain.com.ipsec-nat-t: [no cksum] UDP-encap: ESP(spi=[HIDDEN],seq=0x4b), length 404
00:24:18.414949 IP (tos 0x0, ttl 64, id 47417, offset 0, flags [none], proto UDP (17), length 512)
    sveta.home.org.ipsec-nat-t > 17-11-7-5.no-dns-yet.some.domain.com.ipsec-nat-t: [no cksum] UDP-encap: ESP(spi=[HIDDEN],seq=0x4c), length 484
Back to top
View user's profile Send private message
salahx
Guru
Guru


Joined: 12 Mar 2005
Posts: 530

PostPosted: Thu Oct 02, 2014 5:29 am    Post subject: Reply with quote

OK I finally understand what's going on here.
Code:

ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 125.64.27.8  netmask 255.255.255.255  destination 17.11.7.5                                                         
        ppp  txqueuelen 3  (Point-to-Point Protocol)                                                                                 
        RX packets 4  bytes 34 (34.0 B)                                                                                               
        RX errors 0  dropped 0  overruns 0  frame 0                                                                                   
        TX packets 34  bytes 17794 (17.3 KiB)                                                                                         
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


The "destination" part of the IP is the problem - its the same as the VPN server/ 17.11.7.5. When i configured my VPN server the same way, I see exactly what you see - IPSec packets over the tunnel and the connection disconnects after a few moments. When I connect a Windows client to the server, it says connected, and it doesn't send ipsec packets over the interface.

Linux gets confused here - there TWO routes it can reach 17.11.7.5 - either via eth0 (exterior) or ppp0 (interior). Under linux, it does the latter. In windows it does the former.

But we can get the Windows behavior under linux by adding an extra rule (enter this rule BEFORE you connect to the VPN):
Code:
ip route 17.11.7.5 via  1.2.3.4

This should make Linux choose the exterior route for the l2tp packets, like Windows does. This stop the connection from dropping.

Of course, we still need a route to get out packets into the VPN:
Code:
ip route add 3.5.8.0/24 dev ppp0
Back to top
View user's profile Send private message
Duco Ergo Sum
Apprentice
Apprentice


Joined: 06 Dec 2005
Posts: 154
Location: Winsford

PostPosted: Thu Oct 02, 2014 8:14 am    Post subject: Reply with quote

Unfortunately that hasn't worked.

If I set the rule:
Code:

ip route add 17.11.7.5 via  1.2.3.4


Before
Code:

ipsec up VPN.OFFICE.COM


Then the peer does not respond:
Code:

sending retransmit 5 of request message ID 0, seq 1
sending packet: from 1.2.3.4[500] to 17.11.7.5[500] (184 bytes)
giving up after 5 retransmits
peer not responding, trying again (3/3)
initiating Main Mode IKE_SA VPN-OFFICE-COM[1] to 17.11.7.5
generating ID_PROT request 0 [ SA V V V V ]
sending packet: from 1.2.3.4[500] to 17.11.7.5[500] (184 bytes)
sending retransmit 1 of request message ID 0, seq 1
sending packet: from 1.2.3.4[500] to 17.11.7.5[500] (184 bytes)
sending retransmit 2 of request message ID 0, seq 1
sending packet: from 1.2.3.4[500] to 17.11.7.5[500] (184 bytes)
sending retransmit 3 of request message ID 0, seq 1
sending packet: from 1.2.3.4[500] to 17.11.7.5[500] (184 bytes)


If I add the route after the 'ipsec up' then Openl2tp is not able to create the ppp0 interface.

I have also tried this with:
Code:

ip route add 17.11.7.5 dev eno1
Back to top
View user's profile Send private message
salahx
Guru
Guru


Joined: 12 Mar 2005
Posts: 530

PostPosted: Thu Oct 02, 2014 12:51 pm    Post subject: Reply with quote

Ok, lets try the subtractive approach then. After you bring the connection up, do
Code:

ip route delete 17.11.7.5


You can then add the route into the VPN:
Code:

ip route add 3.5.8.0/24 dev ppp0


Note that because we delete the default ppp0 route, we have to specify it by device name.
Back to top
View user's profile Send private message
Duco Ergo Sum
Apprentice
Apprentice


Joined: 06 Dec 2005
Posts: 154
Location: Winsford

PostPosted: Fri Oct 03, 2014 12:52 am    Post subject: Reply with quote

Well that's brought us a step closer.

Code:

ip route delete 17.11.7.5


Immediately after the sessions created and the ppp0 interface stays up. Sadly however, no traffic crosses it yet. I've tried defining a route as you've specified and using the 'ping -I ppp0' command but nothing.

tcpdumn doesn't show anything either.
Back to top
View user's profile Send private message
salahx
Guru
Guru


Joined: 12 Mar 2005
Posts: 530

PostPosted: Fri Oct 03, 2014 11:18 pm    Post subject: Reply with quote

ping -I should work regardless if a route exists or not. Delete the route without create a new one, verify with tcpdump that ICMP echo requests are being sent over the tunnel. You should see UDP packets over port 4500 on eno1 when you do the ping on ppp0.

One thing about IPSec/L2TP tunnels is there no facility for pushing routes (like, say, openVPN does) to clients. Thus in both Windows and Linux client any servers "behind" the VPN gateway will be inaccessible without adding a manual route.
Back to top
View user's profile Send private message
Duco Ergo Sum
Apprentice
Apprentice


Joined: 06 Dec 2005
Posts: 154
Location: Winsford

PostPosted: Sat Oct 04, 2014 1:36 am    Post subject: Reply with quote

I would like to highlight the ip '1.2.3.8' in the 'ping -I ppp0' command trace. For the purpose of this thread my PC is on '1.2.3.4'. These packets appear to be being sent from an alternate source. The 250.250.250.250 address is an IP which I don't recognise. Port numbers are not given.


Code:

# ping -I ppp0 3.5.8.13
PING 3.5.8.13 (3.5.8.13) from 125.64.27.8 ppp0: 56(84) bytes of data.
^C
--- 3.5.8.13 ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 6999ms

Code:

# tcpdump -i eno1
01:42:26.000837 IP 1.2.3.8.55537 > 250.250.250.250.1900: UDP, length 400
01:42:26.000856 IP 1.2.3.8.55537 > 250.250.250.250.1900: UDP, length 409
01:42:26.000894 IP 1.2.3.8.55537 > 250.250.250.250.1900: UDP, length 446
01:42:26.001418 IP 1.2.3.8.63179 > 250.250.250.250.1900: UDP, length 448
01:42:26.102554 IP 1.2.3.8.57712 > 250.250.250.250.1900: UDP, length 400
01:42:26.102571 IP 1.2.3.8.57712 > 250.250.250.250.1900: UDP, length 409
01:42:26.102672 IP 1.2.3.8.57712 > 250.250.250.250.1900: UDP, length 446
01:42:26.103141 IP 1.2.3.8.55508 > 250.250.250.250.1900: UDP, length 448


Code:

# ping 3.5.8.13
PING 3.5.8.13 (3.5.8.13) 56(84) bytes of data.
^C
--- 3.5.8.13 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 3999ms

Code:

# tcpdump -i eno1
01:42:26.536323 IP sveta.home.org > 3.5.8.13: ICMP echo request, id 6555, seq 2, length 64
01:42:27.536393 IP sveta.home.org > 3.5.8.13: ICMP echo request, id 6555, seq 3, length 64
01:42:28.536325 IP sveta.home.org > 3.5.8.13: ICMP echo request, id 6555, seq 4, length 64
01:42:29.536403 IP sveta.home.org > 3.5.8.13: ICMP echo request, id 6555, seq 5, length 64




Code:

# whois 250.250.250.250
No whois server is known for this kind of object.



Code:

# ping -I ppp0 3.5.8.13
PING 3.5.8.13 (3.5.8.13) from 125.64.27.8 ppp0: 56(84) bytes of data.
^C
--- 3.5.8.13 ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 6999ms




Code:

# tcpdump -vv -i eno1

Code:

sveta.home.org.ipsec-nat-t > 17.11.7.5.no-dns-yet.some.domain.com.ipsec-nat-t: [no cksum] UDP-encap: ESP(spi=0x[HIDDEN],seq=0x8a), length 132
02:06:25.025877 IP (tos 0x0, ttl 4, id 34329, offset 0, flags [none], proto UDP (17), length 346)
    fritz.box.1900 > 250.250.250.250.1900: [udp sum ok] UDP, length 318
02:06:25.026581 IP (tos 0x0, ttl 4, id 34330, offset 0, flags [none], proto UDP (17), length 355)
    fritz.box.1900 > 250.250.250.250.1900: [udp sum ok] UDP, length 327
02:06:25.027424 IP (tos 0x0, ttl 4, id 34331, offset 0, flags [none], proto UDP (17), length 398)
    fritz.box.1900 > 250.250.250.250.1900: [udp sum ok] UDP, length 370
02:06:25.028663 IP (tos 0x0, ttl 4, id 34332, offset 0, flags [none], proto UDP (17), length 410)
    fritz.box.1900 > 250.250.250.250.1900: [udp sum ok] UDP, length 382
02:06:25.029898 IP (tos 0x0, ttl 4, id 34333, offset 0, flags [none], proto UDP (17), length 412)
    fritz.box.1900 > 250.250.250.250.1900: [udp sum ok] UDP, length 384
02:06:25.030951 IP (tos 0x0, ttl 4, id 34334, offset 0, flags [none], proto UDP (17), length 426)
    fritz.box.1900 > 250.250.250.250.1900: [udp sum ok] UDP, length 398
02:06:25.031996 IP (tos 0x0, ttl 4, id 34335, offset 0, flags [none], proto UDP (17), length 390)
    fritz.box.1900 > 250.250.250.250.1900: [udp sum ok] UDP, length 362
02:06:25.643365 IP (tos 0x0, ttl 64, id 55363, offset 0, flags [none], proto UDP (17), length 160)
    sveta.home.org.ipsec-nat-t > 17.11.7.5.no-dns-yet.some.domain.com.ipsec-nat-t: [no cksum] UDP-encap: ESP(spi=0x[HIDDEN],seq=0x8b), length 132
02:06:27.650271 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has fritz.box tell sveta.home.org, length 28
02:06:27.650659 ARP, Ethernet (len 6), IPv4 (len 4), Reply fritz.box is-at 24:65:11:8b:41:13 (oui Unknown), length 46
02:06:28.026000 IP (tos 0x0, ttl 4, id 34336, offset 0, flags [none], proto UDP (17), length 334)
    fritz.box.1900 > 250.250.250.250.1900: [udp sum ok] UDP, length 306
02:06:28.026620 IP (tos 0x0, ttl 4, id 34337, offset 0, flags [none], proto UDP (17), length 343)
    fritz.box.1900 > 250.250.250.250.1900: [udp sum ok] UDP, length 315
02:06:28.027266 IP (tos 0x0, ttl 4, id 34338, offset 0, flags [none], proto UDP (17), length 376)
    fritz.box.1900 > 250.250.250.250.1900: [udp sum ok] UDP, length 348
02:06:28.028470 IP (tos 0x0, ttl 4, id 34339, offset 0, flags [none], proto UDP (17), length 376)
    fritz.box.1900 > 250.250.250.250.1900: [udp sum ok] UDP, length 348
02:06:28.161487 IP (tos 0x0, ttl 4, id 34340, offset 0, flags [none], proto UDP (17), length 151)
    fritz.box.35798 > 250.250.250.250.1900: [udp sum ok] UDP, length 123
02:06:28.162268 IP6 (hlim 254, next-header UDP (17) payload length: 125) [HIDDEN] > ff02::c.1900: [udp sum ok] UDP, length 117
^C
43 packets captured
43 packets received by filter
0 packets dropped by kernel


Last edited by Duco Ergo Sum on Sat Oct 04, 2014 9:47 pm; edited 1 time in total
Back to top
View user's profile Send private message
salahx
Guru
Guru


Joined: 12 Mar 2005
Posts: 530

PostPosted: Sat Oct 04, 2014 4:53 am    Post subject: Reply with quote

I see the similar thing, its normal. We need to filter out the "noise" in tcpdump.
Code:
tcpdump -i eno1 udp port 4500 or proto 50

When you do the ping you should see:
Code:
00:00:00:000000 IP sveta.home.org.ipsec-nat-t > 17.11.7.5.no-dns-yet.some.domain.com: ESP(spi=0xc086fccb,seq=0xc6c), length 148

OR
Code:
00:00:00.000000 IP sveta.home.org.ipsec-nat-t  > 17.11.7.5.no-dns-yet.some.domain.com.ipsec-nat-t: UDP-encap: ESP(spi=0xca66797d,seq=0xd3), length 148

and
Code:
tcpdump -i ppp0

should simultenously print out:
Code:
23:20:22.774538 IP 125.64.27.8 >3.5.8.13: ICMP echo request, id 27658, seq 1, length 64

You may or may not get a reply. Its not important yet we get one, though. traceroute/traceroute won't work yet since we don;t have route (traceroute has an -i option similar to ping -I option, but it didn;t produce any useful data for me).

If all this works, then we know the tunnel is established correctly. Then its a simple matter of adding the routing rules (Windows needs them too).
Back to top
View user's profile Send private message
Duco Ergo Sum
Apprentice
Apprentice


Joined: 06 Dec 2005
Posts: 154
Location: Winsford

PostPosted: Sat Oct 04, 2014 9:51 pm    Post subject: Reply with quote

I think the tunnel is established.

Code:

# ping -I ppp0 3.5.8.13
PING 3.5.8.13 (3.5.8.13) from 125.64.27.8 ppp0: 56(84) bytes of data.
^C
--- 3.5.8.13 ping statistics ---
12 packets transmitted, 0 received, 100% packet loss, time 10999ms


Code:

# tcpdump -i eno1 udp port 4500 or proto 50
error : ret -1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno1, link-type EN10MB (Ethernet), capture size 65535 bytes
22:33:44.409464 IP sveta.home.org.ipsec-nat-t > 17-11-7-5.no-dns-yet.some.domain.com.ipsec-nat-t: UDP-encap: ESP(spi=[HIDDEN],seq=0xf), length 132
22:33:45.408985 IP sveta.home.org.ipsec-nat-t > 17-11-7-5.no-dns-yet.some.domain.com.ipsec-nat-t: UDP-encap: ESP(spi=[HIDDEN],seq=0x10), length 132
22:33:46.408984 IP sveta.home.org.ipsec-nat-t > 17-11-7-5.no-dns-yet.some.domain.com.ipsec-nat-t: UDP-encap: ESP(spi=[HIDDEN],seq=0x11), length 132
22:33:47.408997 IP sveta.home.org.ipsec-nat-t > 17-11-7-5.no-dns-yet.some.domain.com.ipsec-nat-t: UDP-encap: ESP(spi=[HIDDEN],seq=0x12), length 132
22:33:48.409002 IP sveta.home.org.ipsec-nat-t > 17-11-7-5.no-dns-yet.some.domain.com.ipsec-nat-t: UDP-encap: ESP(spi=[HIDDEN],seq=0x13), length 132
22:33:49.408998 IP sveta.home.org.ipsec-nat-t > 17-11-7-5.no-dns-yet.some.domain.com.ipsec-nat-t: UDP-encap: ESP(spi=[HIDDEN],seq=0x14), length 132
22:33:50.408972 IP sveta.home.org.ipsec-nat-t > 17-11-7-5.no-dns-yet.some.domain.com.ipsec-nat-t: UDP-encap: ESP(spi=[HIDDEN],seq=0x15), length 132
22:33:51.408961 IP sveta.home.org.ipsec-nat-t > 17-11-7-5.no-dns-yet.some.domain.com.ipsec-nat-t: UDP-encap: ESP(spi=[HIDDEN],seq=0x16), length 132
22:33:52.409002 IP sveta.home.org.ipsec-nat-t > 17-11-7-5.no-dns-yet.some.domain.com.ipsec-nat-t: UDP-encap: ESP(spi=[HIDDEN],seq=0x17), length 132
22:33:53.408959 IP sveta.home.org.ipsec-nat-t > 17-11-7-5.no-dns-yet.some.domain.com.ipsec-nat-t: UDP-encap: ESP(spi=[HIDDEN],seq=0x18), length 132
22:33:54.408996 IP sveta.home.org.ipsec-nat-t > 17-11-7-5.no-dns-yet.some.domain.com.ipsec-nat-t: UDP-encap: ESP(spi=[HIDDEN],seq=0x19), length 132
22:33:55.408991 IP sveta.home.org.ipsec-nat-t > 17-11-7-5.no-dns-yet.some.domain.com.ipsec-nat-t: UDP-encap: ESP(spi=[HIDDEN],seq=0x1a), length 132
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel





Code:

# ping -I ppp0 3.5.8.13
PING 3.5.8.13 (3.5.8.13) from 125.64.27.8 ppp0: 56(84) bytes of data.
^C
--- 3.5.8.13 ping statistics ---
17 packets transmitted, 0 received, 100% packet loss, time 15999ms


Code:

# tcpdump -i ppp0
error : ret -1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
22:36:09.938948 IP 125.64.27.8 > 3.5.8.13: ICMP echo request, id 4297, seq 3, length 64
22:36:10.939018 IP 125.64.27.8 > 3.5.8.13: ICMP echo request, id 4297, seq 4, length 64
22:36:11.939031 IP 125.64.27.8 > 3.5.8.13: ICMP echo request, id 4297, seq 5, length 64                                         
22:36:12.938930 IP 125.64.27.8 > 3.5.8.13: ICMP echo request, id 4297, seq 6, length 64                                         
22:36:13.938953 IP 125.64.27.8 > 3.5.8.13: ICMP echo request, id 4297, seq 7, length 64                                         
22:36:14.938950 IP 125.64.27.8 > 3.5.8.13: ICMP echo request, id 4297, seq 8, length 64                                         
22:36:15.939012 IP 125.64.27.8 > 3.5.8.13: ICMP echo request, id 4297, seq 9, length 64                                         
22:36:16.938958 IP 125.64.27.8 > 3.5.8.13: ICMP echo request, id 4297, seq 10, length 64                                       
22:36:17.939055 IP 125.64.27.8 > 3.5.8.13: ICMP echo request, id 4297, seq 11, length 64                                       
22:36:18.939045 IP 125.64.27.8 > 3.5.8.13: ICMP echo request, id 4297, seq 12, length 64                                       
22:36:19.938930 IP 125.64.27.8 > 3.5.8.13: ICMP echo request, id 4297, seq 13, length 64                                       
22:36:20.938929 IP 125.64.27.8 > 3.5.8.13: ICMP echo request, id 4297, seq 14, length 64                                       
22:36:21.939036 IP 125.64.27.8 > 3.5.8.13: ICMP echo request, id 4297, seq 15, length 64                                       
22:36:22.938933 IP 125.64.27.8 > 3.5.8.13: ICMP echo request, id 4297, seq 16, length 64                                       
22:36:23.939027 IP 125.64.27.8 > 3.5.8.13: ICMP echo request, id 4297, seq 17, length 64                                       
^C                                                                                                                                   
15 packets captured                                                                                                                   
15 packets received by filter                                                                                                         
0 packets dropped by kernel
Back to top
View user's profile Send private message
salahx
Guru
Guru


Joined: 12 Mar 2005
Posts: 530

PostPosted: Sat Oct 04, 2014 11:30 pm    Post subject: Reply with quote

Yes, the tunnel is established! Now its just a matter of setting the routes

You can can try routing ALL traffic through the tunnel,. but its kinda tricky:
Code:

ip route add 17.11.7.5 via 1.2.3.4 dev eno1
ip route delete default
ip route add default via 125.64.27.8 dev ppp0


After you're done using the tunnel you'll have to restore the old default route manually.
Back to top
View user's profile Send private message
Duco Ergo Sum
Apprentice
Apprentice


Joined: 06 Dec 2005
Posts: 154
Location: Winsford

PostPosted: Mon Oct 06, 2014 8:42 am    Post subject: Reply with quote

This is just a quick response.

Your proposal above kills ppp0.

I'm looking into a kind of 2 NICs idea but writing my response, I found I've made a big mistake and need to revisit everything I've done today. So I will respond again after I've had a chance to go over this again.
Back to top
View user's profile Send private message
Duco Ergo Sum
Apprentice
Apprentice


Joined: 06 Dec 2005
Posts: 154
Location: Winsford

PostPosted: Tue Oct 07, 2014 11:52 pm    Post subject: Reply with quote

My theory at this point is that what might be happening is that when I ping across ppp0 packets are sent out with the local sub-net ip address of my PC. They reach their destination and it responds, sending packets back but to another possible host else where. Of cause my PC doesn't see anything because there's no traffic going it's way.

Maybe that's just my imagination... but with that in mind I found this http://kindlund.wordpress.com/2007/11/19/configuring-multiple-default-routes-in-linux/ and tried to configure ppp0 as a second independent network device.

Code:

# netstat -anr
Kernel IP routing table                                                                                                               
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface                                                       
0.0.0.0         1.2.3.253      0.0.0.0         UG        0 0          0 eno1                                                         
0.0.0.0         1.2.3.253      0.0.0.0         UG        0 0          0 eno1                                                         
1.2.3.0        0.0.0.0         255.255.255.0   U         0 0          0 eno1                                                         
127.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0 lo                                                           
127.0.0.0       127.0.0.1       255.0.0.0       UG        0 0          0 lo                                                           

                                                                                         
 # ip route add 3.5.8.0/24 dev ppp0 src 125.64.27.8 table VPN
 # ip route add default dev ppp0 table VPN
 # ip rule show
0:      from all lookup local                                                                                                         
220:    from all lookup 220                                                                                                           
32766:  from all lookup main                                                                                                         
32767:  from all lookup default                                                                                                       
 # ip rule add from 125.64.27.8/32 table VPN                                                                             
 # ip rule add to 125.64.27.8/32 table VPN
 # ip rule show
0:      from all lookup local                                                                                                         
218:    from all to 125.64.27.8 lookup VPN                                                                                           
219:    from 125.64.27.8 lookup VPN                                                                                                   
220:    from all lookup 220                                                                                                           
32766:  from all lookup main                                                                                                         
32767:  from all lookup default                                                                                                       
 # ping 3.5.8.13                                                                                                   
PING 3.5.8.13 (3.5.8.13) 56(84) bytes of data.                                                                           
^C                                                                                                                                   
--- 3.5.8.13 ping statistics ---                                                                                               
21 packets transmitted, 0 received, 100% packet loss, time 19999ms                                                                   
                                                                                                                                     
 # ip route flush cache                                                                                                   
 # ping 3.5.8.13                                                                                                   
PING 3.5.8.13 (3.5.8.13) 56(84) bytes of data.                                                                           
^C                                                                                                                                   
--- 3.5.8.13 ping statistics ---                                                                                               
6 packets transmitted, 0 received, 100% packet loss, time 4999ms                                                                     
                                                                                                                                     
 # netstat -anr                                                                                                           
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         1.2.3.253      0.0.0.0         UG        0 0          0 eno1
0.0.0.0         1.2.3.253      0.0.0.0         UG        0 0          0 eno1
1.2.3.0        0.0.0.0         255.255.255.0   U         0 0          0 eno1
127.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0 lo
127.0.0.0       127.0.0.1       255.0.0.0       UG        0 0          0 lo
 # ip route show
default via 1.2.3.253 dev eno1  proto static
default via 1.2.3.253 dev eno1  metric 7
1.2.3.0/24 dev eno1  proto kernel  scope link  src 1.2.3.4  metric 1
127.0.0.0/8 dev lo  scope host
127.0.0.0/8 via 127.0.0.1 dev lo


While I acknowledge that the routes and rules which I've set above are only live for the session, I don't see them doing anything. Thank you for your patience.
Back to top
View user's profile Send private message
salahx
Guru
Guru


Joined: 12 Mar 2005
Posts: 530

PostPosted: Wed Oct 08, 2014 1:14 am    Post subject: Reply with quote

I suspect that, given that neither your Windows 7 nor 8.1 machines work either (just like our Linux machine, they make the tunnel but recieve no traffic), the remainder of the problem is on the other side, not us. We have a good tunnel, data crosses the tunnel. but whatever is on the other side isn't getting the packets even though they cross the tunnel due to something on the other side of the tunnel.

At this point, i would recommend try to get the Windows machine working, since you'll probably need the help of the IT/HElpdesk people to remove the impedement.
Back to top
View user's profile Send private message
Duco Ergo Sum
Apprentice
Apprentice


Joined: 06 Dec 2005
Posts: 154
Location: Winsford

PostPosted: Wed Oct 08, 2014 8:50 am    Post subject: Reply with quote

I am inclined to agree.

You're right, the ipsec/l2tp tunnel is established and stable. It doesn't seem right to mark this topic as [Solved] as we can't get any traffic to flow over the link.

I will pursue the IT/Helpdesk and attempt to the Windows machines working.


--
A network engineer decided to join the Territorial Army. On his first weekend he was taken to the rifle range and handed a rifle complete with bullets. He was instructed to fire 10 shots at the target down the range.

After he'd fired several shots, the word came back from the target area that every shot had completely missed the target. The engineer looked at his rifle, then up at the target, looked down at his rifle again then back up at the target.

He put his finger over the end of the barrel and squeezed the trigger. His finger was blown clean off. After cursing, he yelled down towards the target area, "Well its leaving here just fine, The problem must be at your end !!!"
Back to top
View user's profile Send private message
Duco Ergo Sum
Apprentice
Apprentice


Joined: 06 Dec 2005
Posts: 154
Location: Winsford

PostPosted: Mon Oct 13, 2014 11:46 pm    Post subject: Here we go again... Reply with quote

Just when I thought I could let this all go.

I have discovered, that there is a firewall which rejects pings. This I am assuming is a Windows firewall. When I asked a colleague to ping my office PC from his PC in the office, he did not get a response. Since then I have reconfigured the firewall on my office PC.

The interesting part of this is that as a result I have tested the network from Windows again, this time using the remote desktop application and this is able to connect. This works for both Windows 8.1 and Windows 7.

Unfortunately, there does not appear to be any traffic when it comes to remote desktop from Linux. I know that remote desktop works because I am able work around this little problem by connecting via a remote desktop to a local Windows Machine which is then able to connect to my office PC.

This shows that routing is not at issue nor is remote desktop.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Goto page Previous  1, 2, 3, 4, 5  Next
Page 4 of 5

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum