02-17-2020 08:15 AM
Ive purchased a Cisco RV340 to use a site to site VPN to another company. I have setup the VPN as per their document without issues, but when it comes to traffic across said tunnel, this is where I am having issues.
I started out with a Draytek 2862, then another Draytek on another line - Draytek support couldnt help me and thought it was the other end.
I then ordered this Cisco RV340 after this other company assured me that the issue is at my end. They are using a Juniper SRX240.
The tunnel is up and online using their P1 and P2 proposal settings. The only IP address they say I should be able to ping through this tunnel is 192.168.168.79 (a hosted IBM i Partition).
I have fiddled around with static routes, VPN settings, turned the firewall off and they are still pointing the finger at my end.
Details of VPN if relevant;
IPSec IKEv1
P1: 3DES SHA-1 G2
P2: ESP AES-256 SHA-1 G2
Pre shared key
Our lan 192.168.0.1
Their server 192.168.168.79
Any help would be great.
02-17-2020 11:21 AM
Do you have right ACL to ping far end device ?
example :
02-18-2020 01:22 AM
I have set up a basic allow all ACL for this task, and have disabled the firewall.
See ACL below;
02-18-2020 01:38 PM
If you do not have support on far end to fix this, never going to work.
here is guide for rereference - since you told Tunnel UP and running :
here is diagnosis to start with.
1. when far end ping your IP - what is your Logs shows ?
2. when you ping to far end IP address - do they see your IP in Logs ?
3. what is the device you pinging ( check any FW in that device) - including your device too.
02-20-2020 01:32 AM
Just to clarify, I do have support at the other end, but it is managed by another company, not by me.
They have set up a VPN server on their Juniper Networks Router, then given me a document for connection.
I have used 5 different routers and two different broadband lines to connect this VPN all of which are having issues pinging the IP that they say is pingable.
I have been on multiple support calls with them using a Draytek and they could not see any traffic, hence why I have purchased this cisco as an alternative - but the same symptoms apply.
I have a conference call with them later today to try and resolve this as im sure ive got everything set correctly.
Will update this once I find out more.
02-20-2020 06:54 AM
Thank for the clarification.
a couple of things while you contacting them or phone.
When you pinging far-end IP address.
1. check on your FW, is the passing FW outside interface?
2 if that is passing, so it leaving your network.
3. they should also have captured on their FW, the same packet they can see yes or no.
4. The only PING allowed or any other ports also opened, if any other ports opened, try telnet x.x.x. (PORT) see you able to connect and the same will be viewed on your debug or logs.
02-24-2020 01:58 AM
With the above details for the VPN, we could not get any traffic working. I could send a ping and see it leave, but the other end did not see it arrive and vice versa.
We decided to completely recreate the VPN using a different PSK, no PFS, different encryption and Group and we suddenly had a working VPN with traffic. I can only assume that one of the settings between the Juniper and the Cisco were not compatible or not working correctly.
This issue is therefore resolved. I advise anyone in the future who is having odd issues with the VPN connecting but not allowing traffic to create a new VPN with different settings as a test.
02-25-2020 07:14 AM
Whilst I had this working on the bench here in the office, I took this unit on site and installed it behind a Draytek router and I could not get the VPN working.
Thinking that this was the Draytek messing around with things, I have now set the Cisco up as the main router with an external modem and wireless AP.
The VPN is doing exactly the same thing as it was when I started this thread. I have all the details correct, the VPN is established and online but we cannot pass traffic either way.
I have been playing with static routes and ACL's for a few hours and it is still not working. The logs show packets leaving the Cisco as below;
2020-Feb-25, 14:49:27 GMT
info
firewall
kernel: [12098.582779] FIREWALL ACCEPT:IN=eth3.1 OUT=ppoe-wan1p DST_MAC=7c:31:0e:ed:66:48 SRC_MAC=:70:4d:7b:2f:51:02 src=192.168.0.116 DST=192.168.168.79 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=50688 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=1038 MARK=0xff00
192.168.0.116 is a PC on the local network.
192.168.168.79 is a server on the other end of the VPN.
This traffic never arrives in the Juniper router. The Juniper can also send traffic but it is not returned.
I am pretty certain that there is some sort of routing/firmware bugs or something else causing these issues as I have been fiddling with this for hours and it worked from our office on the same unit.
02-25-2020 07:28 AM
I have just removed the IPSec profile and the VPN config, saved changes then rebuilt all to end up with the same issue.
02-25-2020 08:21 AM
Far end has also removed all VPN details and rebuilt, same result.
VPN Log from the cisco showing it is connected ok;
2020-02-25T15:55:13+00:00 <info>charon: 07[CHD] updown: Cleared 0 matching VPN connections
2020-02-25T15:55:13+00:00 <info>charon: 07[CHD] updown: Clear VPN connections: (OK)
2020-02-25T15:55:13+00:00 <info>charon: Last message '07[IKE] CHILD_SA s2s' repeated 1 times, supressed by syslog-ng on routerED6648
2020-02-25T15:55:13+00:00 <info>charon: 07[IKE] CHILD_SA s2s_Dancerace-1{33} established with SPIs c6747729_i a6014bd4_o and TS 192.168.0.0/24 === 192.168.168.79/32
2020-02-25T15:55:13+00:00 <info>charon: 07[ENC] parsed QUICK_MODE request 2810221916 [ HASH ]
2020-02-25T15:55:13+00:00 <info>charon: 07[NET] received packet: from 87.237.70.90[500] to 81.130.149.226[500] (76 bytes)
2020-02-25T15:55:13+00:00 <info>charon: 16[NET] sending packet: from 81.130.149.226[500] to 87.237.70.90[500] (188 bytes)
2020-02-25T15:55:13+00:00 <info>charon: 16[ENC] generating QUICK_MODE response 2810221916 [ HASH SA No ID ID ]
2020-02-25T15:55:13+00:00 <info>charon: 16[ENC] parsed QUICK_MODE request 2810221916 [ HASH SA No ID ID ]
2020-02-25T15:55:13+00:00 <info>charon: 16[NET] received packet: from 87.237.70.90[500] to 81.130.149.226[500] (172 bytes)
2020-02-25T15:55:13+00:00 <info>charon: 14[NET] sending packet: from 81.130.149.226[500] to 87.237.70.90[500] (92 bytes)
2020-02-25T15:55:13+00:00 <info>charon: 14[ENC] generating ID_PROT response 0 [ ID HASH ]
2020-02-25T15:55:13+00:00 <info>charon: 14[IKE] maximum IKE_SA lifetime 28777s
2020-02-25T15:55:13+00:00 <info>charon: 14[IKE] scheduling reauthentication in 28597s
2020-02-25T15:55:13+00:00 <info>charon: Last message '14[IKE] IKE_SA s2s_D' repeated 1 times, supressed by syslog-ng on routerED6648
2020-02-25T15:55:13+00:00 <info>charon: 14[IKE] IKE_SA s2s_Dancerace[38] established between 81.130.149.226[81.130.149.226]...87.237.70.90[87.237.70.90]
2020-02-25T15:55:13+00:00 <info>charon: 14[CFG] selected peer config s2s_Dancerace
2020-02-25T15:55:13+00:00 <info>charon: 14[CFG] looking for pre-shared key peer configs matching 81.130.149.226...87.237.70.90[87.237.70.90]
2020-02-25T15:55:13+00:00 <info>charon: 14[ENC] parsed ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
2020-02-25T15:55:13+00:00 <info>charon: 14[NET] received packet: from 87.237.70.90[500] to 81.130.149.226[500] (108 bytes)
2020-02-25T15:55:13+00:00 <info>charon: 06[NET] sending packet: from 81.130.149.226[500] to 87.237.70.90[500] (332 bytes)
2020-02-25T15:55:13+00:00 <info>charon: 06[ENC] generating ID_PROT response 0 [ KE No NAT-D NAT-D ]
2020-02-25T15:55:13+00:00 <info>charon: 06[IKE] FSLDBG: Now searching for PSK with :my_id,me,other_id,other: '81.130.149.226'[81.130.149.226] - '87.237.70.90'[87.237.70.90]
2020-02-25T15:55:13+00:00 <info>charon: 06[ENC] parsed ID_PROT request 0 [ KE No NAT-D NAT-D ]
2020-02-25T15:55:13+00:00 <info>charon: 06[NET] received packet: from 87.237.70.90[500] to 81.130.149.226[500] (316 bytes)
2020-02-25T15:55:13+00:00 <info>charon: 08[NET] sending packet: from 81.130.149.226[500] to 87.237.70.90[500] (164 bytes)
2020-02-25T15:55:13+00:00 <info>charon: 08[ENC] generating ID_PROT response 0 [ SA V V V V ]
2020-02-25T15:55:13+00:00 <info>charon: Last message '08[IKE] 87.237.70.90' repeated 1 times, supressed by syslog-ng on routerED6648
2020-02-25T15:55:13+00:00 <info>charon: 08[IKE] 87.237.70.90 is initiating a Main Mode IKE_SA
2020-02-25T15:55:13+00:00 <info>charon: 08[ENC] received unknown vendor ID: 69:93:69:22:87:41:c6:d4:ca:09:4c:93:e2:42:c9:de:19:e7:b7:c6:00:00:00:05:00:00:05:00
2020-02-25T15:55:13+00:00 <info>charon: 08[IKE] received NAT-T (RFC 3947) vendor ID
2020-02-25T15:55:13+00:00 <info>charon: 08[IKE] received draft-ietf-ipsec-nat-t-ike-03 vendor ID
2020-02-25T15:55:13+00:00 <info>charon: 08[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
2020-02-25T15:55:13+00:00 <info>charon: 08[IKE] received draft-ietf-ipsec-nat-t-ike-02 vendor ID
2020-02-25T15:55:13+00:00 <info>charon: 08[IKE] received draft-ietf-ipsec-nat-t-ike-00 vendor ID
2020-02-25T15:55:13+00:00 <info>charon: 08[IKE] received draft-stenberg-ipsec-nat-traversal-02 vendor ID
2020-02-25T15:55:13+00:00 <info>charon: 08[IKE] received draft-stenberg-ipsec-nat-traversal-01 vendor ID
2020-02-25T15:55:13+00:00 <info>charon: 08[IKE] received DPD vendor ID
2020-02-25T15:55:13+00:00 <info>charon: 08[ENC] parsed ID_PROT request 0 [ SA V V V V V V V V V ]
2020-02-25T15:55:13+00:00 <info>charon: 08[NET] received packet: from 87.237.70.90[500] to 81.130.149.226[500] (288 bytes)
Firewall log;
2020-02-25T16:07:59+00:00 <info>kernel: [16810.650983] FIREWALL ACCEPT:IN=ppoe-wan1p OUT=eth3.1 DST_MAC= src=192.168.168.79 DST=192.168.0.250 LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=21184 PROTO=TCP SPT=63852 DPT=9100 WINDOW=65535 RES=0x00 SYN URGP=0 MARK=0xff00
2020-02-25T15:59:19+00:00 <info>kernel: [16290.368559] FIREWALL ACCEPT:IN=eth3.1 OUT=ppoe-wan1p DST_MAC=7c:31:0e:ed:66:48 SRC_MAC=:78:24:af:39:09:05 src=192.168.0.134 DST=192.168.168.79 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=57396 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=23 MARK=0xff00
2020-02-25T15:59:14+00:00 <info>kernel: [16285.458338] FIREWALL ACCEPT:IN=eth3.1 OUT=ppoe-wan1p DST_MAC=7c:31:0e:ed:66:48 SRC_MAC=:78:24:af:39:09:05 src=192.168.0.134 DST=192.168.168.79 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=57395 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=22 MARK=0xff00
2020-02-25T15:46:09+00:00 <info>kernel: [15500.178614] FIREWALL ACCEPT:IN=ppoe-wan1p OUT=eth3.1 DST_MAC= src=192.168.168.79 DST=192.168.0.250 LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=7059 PROTO=TCP SPT=63723 DPT=9100 WINDOW=65535 RES=0x00 SYN URGP=0 MARK=0xff00
2020-02-25T15:45:21+00:00 <info>kernel: [15452.208503] FIREWALL ACCEPT:IN=ppoe-wan1p OUT=eth3.1 DST_MAC= src=192.168.168.79 DST=192.168.0.250 LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=6683 PROTO=TCP SPT=63723 DPT=9100 WINDOW=65535 RES=0x00 SYN URGP=0 MARK=0xff00
192.168.0.250 is the printer that this other company are trying to contact across the VPN.
192.168.0.134 is a desktop PC I was attempting a ping from.
02-26-2020 06:48 AM
Another update on this;
Some print traffic managed to get through yesterday during testing and again this morning however I still cannot get ping traffic working from my end to the remote end.
I have spend another couple of hours trying to troubleshoot this, and I can see entries in the firewall log to say the traffic is being passed, but still cannot get a ping working.
I have created various ACL rules, dropped the firewall, created multiple static routes, recreated the whole VPN profile and config.
2020-02-25T15:55:13+00:00 <info>charon: 07[IKE] CHILD_SA s2s_Dancerace-1{33} established with SPIs c6747729_i a6014bd4_o and TS 192.168.0.0/24 === 192.168.168.79/32
Can we turn off SPI in case this is causing havoc? Looking online this looks like the answer is no...
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide