FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

14455 questions

17168 answers

28195 comments

0 members

We are migrating to our new platform at https://community.teltonika.lt. Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
0 votes
713 views 7 comments
by anonymous
Hi

I have a RUTX50 i want to make a IPsec tunnel between and a PaloAlto FW.

It is an aggresive VPN tunnel.

Running firmware RUTX_R_00.07.04

The tunnel comes up but not traffic is allowed through. I have tried what is mentioned here:

But that haven't helped.

RUTX network: 10.64.0.0/24

Remote network: 192.168.15.0/24

root@Teltonika-RUTX50:~# ipsec statusall

Status of IKE charon daemon (strongSwan 5.9.2, Linux 5.4.229, armv7l):

  uptime: 12 minutes, since Mar 21 13:41:16 2023

  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2

  loaded plugins: charon aes des sha2 sha1 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs8 pgp pem openssl gmp xcbc hmac kernel-netlink socket-default stroke vici updown eap-identity eap-mschapv2 xauth-generic

Listening IP addresses:

  10.64.0.1

  fda2:c3a9:5724::1

  10.xxxxxxxxx

Connections:

AdvHost-AdvHost_c:  %any...5.xxxxxxx  IKEv2

AdvHost-AdvHost_c:   local:  [10.64.0.1] uses pre-shared key authentication

AdvHost-AdvHost_c:   remote: [192.168.15.1] uses pre-shared key authentication

AdvHost-AdvHost_c:   child:  10.64.0.0/24 === 192.168.15.0/24 192.168.40.0/24 TUNNEL

Security Associations (1 up, 0 connecting):

AdvHost-AdvHost_c[1]: ESTABLISHED 12 minutes ago, 10.xxxxxxx[10.64.0.1]...5.xxxxxx[192.168.15.1]

AdvHost-AdvHost_c[1]: IKEv2 SPIs: cb8cf8d7f59f0db9_i* 7e4c5d43acb25af5_r, pre-shared key reauthentication in 7 hours

AdvHost-AdvHost_c[1]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_384

AdvHost-AdvHost_c{1}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: cb018cff_i 806fb729_o

AdvHost-AdvHost_c{1}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 9344 bytes_o (156 pkts, 0s ago), rekeying in 34 minutes

AdvHost-AdvHost_c{1}:   10.64.0.0/24 === 192.168.15.0/24

root@Teltonika-RUTX50:~# iptables -t nat -n -L | grep policy | grep ipsec

ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            policy match dir out pol ipsec

ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            policy match dir out pol ipsec /* !fw3: Exclude-IPsec-from-NAT */

Does anyone have an idea on how to get this up and running?

I have tried to reset the device and create the VPN tunnel again fro scratch.

My guess is it something to do with FW on the Box that is not functionally properly. Have tried in multiple ways to have "local" and "remote" FW on and off under advanced but doesn't seem to fix the issue.

1 Answer

0 votes
by anonymous

Hello,

Does any data pass through the tunnel, or neither side is reachable from the moment the tunnel is established?

Also, I would like you to attach a troubleshoot file to your question. Please, replicate the issue, then access router's WebUI, go to System -> Administration -> Troubleshoot section and download troubleshoot file from there. The logs in the file might provide more insight into the issue.

Attached files are private and visible only to Teltonika Moderators.

Best regards,

Best answer
by anonymous
i have added attached it
by anonymous

IKEv2 does not have Aggressive mode, though in my testing having it enabled did not interfere with tunnel establishment. If this option is necessary, use IKEv1 instead.

Could you in RUTX50 IPsec settings change option Mode from Start to Route and see if that has any effect?

Otherwise, there do not seem to be any issues in regards to your configuration.

How do you determine that no traffic goes through the tunnel, as there appears to be messages exchanged between the devices every 5 seconds?

Does the traffic fail to flow both ways, are you not able to ping 10.64.0.1 from 192.168.15.1 and vice versa, or traffic does not flow in one of the directions?

Best regards,

by anonymous
Hi

Changing to Route does not change the outcome.

I'm still not able to make any ping or any other protocols over the VPN.
all my pings just time out and other services are not able to connect.

Are you sure there is nothing related to the FW that is blocking this traffic?
by anonymous

Hello,

I have replicated majority of your configuration, but did not experience any issue with traffic forwarding within the tunnel.

Could you open two SSH windows logged in to the router. In one of them, enter, the following command:

  • tcpdump -n -i qmimux0 -w /tmp/capture.pcap esp or udp port 4500
It will enable packet capture to a file.
In the next, execute command:
  • /etc/init.d/ipsec restart
It will restart IPsec connection, which will allow to capture its traffic from connection initiation moment. I would also need you to try pinging devices from both sides, while packets are being captured:
  • RUTX50 to Paloalto FW;
  • PaloAlto FW to RUTX50.
Once done, after some time, extract the capture file from the device using scp/WinSCP as instructed here. It will be located in /tmp/ directory. Attach this file to your question.

Best regards,

by anonymous
Hi

I have done as requested and uploaded the files.

I don't have SSH access to the PaloAlto firewall so i have pinged the server i have access to instead (192.168.15.11)
by anonymous

So both, packet capture and troubleshoot file (AdvHost-AdvHost_c{2}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 32088 bytes_o (382 pkts, 1s ago), rekeying in 39 minutes) indicate that data is sent through the IPsec tunnel from Teltonika side, but no data matching IPsec policy is received from the remote PaloAlto side.

I would advise to check PaloAlto side:

  • If there are no routing issues, incorrect routes or overlapping subnets;
  • Check traffic policies: do not apply NAT for traffic from 192.168.15.0/24 subnet destined to 10.64.0.0/24;
  • See if there is no "implicit deny all" rule rejecting traffic to be sent through the tunnel.

Best regards,

by anonymous
Hi

I got it fixed. The error was on the PaloAlto not haveing Nat-T enabled on their side.