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
614 views 9 comments
by anonymous
Hello,

routers used by our company are connected to remote server using IPSec. It's "one-side" tunnel - we use remote subnet but don't share anything from us. This configuration worked great for a long time but suddenly a routing of remote subnet stopped working in the case of two devices (other are ok). Both have a common NAT (and always had). ISP and admin of the second network didn't find any issue (connection looks valid from his point of view). Any service restarts and router reboots don't help.
Firmware version: 7.02.04 (the latest) but on 7.01.04 it was similar.

Some output (from one router):

# cat /var/ipsec/ipsec.conf
# generated by /etc/init.d/ipsec
version 2

conn PAK-PAK_c
  left=%any
  right=<censored>
  leftfirewall=yes
  rightfirewall=yes
  ikelifetime=24h
  lifetime=12h
  margintime=9m
  keyingtries=3
  dpdaction=none
  dpddelay=30s
  dpdtimeout=90s
  leftauth=psk
  rightauth=psk
  rightsubnet=10.212.143.0/24
  auto=start
  leftsubnet=192.168.1.0/24
  leftid=<censored>
  forceencaps=no
  type=tunnel
  keyexchange=ikev2
  esp=aes128-sha256-modp1536
  ike=aes128-sha256-modp1536
  rightsubnet=10.212.143.0/24

# ipsec status
Security Associations (1 up, 0 connecting):
   PAK-PAK_c[6]: ESTABLISHED 10 hours ago, 192.168.192.201[<censored>]..<censored>[<censored>]
   PAK-PAK_c{11}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c18d8d53_i 1a4f1a69_o
   PAK-PAK_c{11}:   192.168.1.0/24 === 10.212.143.0/24

# ip route show table 220
10.212.143.0/24 via 192.168.192.254 dev eth1 proto static src 192.168.1.1

# traceroute 10.212.143.73
traceroute to 10.212.143.73 (10.212.143.73), 30 hops max, 38 byte packets
 1  192.168.192.254 (192.168.192.254)  3.230 ms  1.283 ms  1.145 ms
 2  10.0.0.109 (10.0.0.109)  12.199 ms  6.439 ms  7.442 ms
 3  <censored public IP> (<censored public IP>)  12.660 ms  16.864 ms  *

As you see, it tries to route a remote subnet via Internet instead of a tunnel.
Dump is null in the case of correct working routers.
192.168.192.0/24 is WAN subnet, 192.168.1.1/24 is LAN subnet, 10.212.143.0/24 is remote subnet.

Thank you for help.

1 Answer

0 votes
by anonymous
Hello,

Have you tried with forceencaps=yes ? Set option forceencaps 'yes' in /etc/config/ipsec section conn PAK-PAK_c and restart the tunnel.

Check also the leftsubnet value the ip route show table 220 output looks dubious (the src part). I can also see that your config doesn't have a leftsourceip field defined.

Regards,
by anonymous
Thanks for reply. I set forceencaps=yes (and a service applied it in /var/ipsec/ipsec.conf) but it still doesn't work.
Parameter 'leftsourceip' never was defined and it worked (and in other routers works even now). So I think it isn't a reason rather.
by anonymous
Could you post a similar configuration for a working router ? ipsec.conf, ip route  ipsec statusall ...
by anonymous
Please find config and outputs below:

# cat /var/ipsec/ipsec.conf

# generated by /etc/init.d/ipsec
version 2

conn PAK-PAK_c
  left=%any
  right=<censored>
  leftfirewall=yes
  rightfirewall=yes
  ikelifetime=24h
  lifetime=12h
  margintime=9m
  keyingtries=3
  dpdaction=none
  dpddelay=30s
  dpdtimeout=90s
  leftauth=psk
  rightauth=psk
  auto=start
  leftsubnet=192.168.1.0/24
  leftid=<censored>
  forceencaps=no
  type=tunnel
  keyexchange=ikev2
  esp=aes128-sha256-modp1536
  ike=aes128-sha256-modp1536
  rightsubnet=10.212.142.0/24

# ipsec status
Security Associations (1 up, 0 connecting):
   PAK-PAK_c[16]: ESTABLISHED 11 hours ago, 10.201.60.141[<censored>]...<censored>[<censored>]
   PAK-PAK_c{39}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: cc162bb6_i 1a4f1a74_o
   PAK-PAK_c{39}:   192.168.1.0/24 === 10.212.142.0/24

# ip route show table 220
10.212.142.0/24 via 10.201.60.200 dev eth1 proto static src 192.168.1.1

# traceroute 10.212.142.72
traceroute to 10.212.142.72 (10.212.142.72), 30 hops max, 38 byte packets
 1  *  *

# ping -c 3 10.212.142.72
PING 10.212.142.72 (10.212.142.72): 56 data bytes
64 bytes from 10.212.142.72: seq=0 ttl=63 time=65.184 ms
64 bytes from 10.212.142.72: seq=1 ttl=63 time=62.208 ms
64 bytes from 10.212.142.72: seq=2 ttl=63 time=64.041 ms

--- 10.212.142.72 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 62.208/63.811/65.184 ms

10.201.60.0/24 is WAN subnet, 192.168.1.1/24 is LAN subnet, 10.212.142.0/24 is remote subnet.
by anonymous

I didn't spot it the first time but rightsubnet appears twice in the failing config.

Apparently the "Exclude IPSEC from NAT" rule isn't enabled by default, could you check it with:

iptables -t nat -n -L | grep 'pol ipsec'

If the output is empty, go to Network->Firewall->Nat rules and enable it.

by anonymous
I noticed it (doubled rightsubnet) and removed manually. After "ipsec restart" "ipsec update" and again "ipsec restart" nothing was changed unfortunately. I'll try to connect with the same config on another router.
by anonymous
Please check first the iptables rule as described above, I was just hit by the same snag.
by anonymous
Yes, you're right! It fixed an issue in one router but what is it possible? It worked for few months before.
I'll try with the second router.
by anonymous
The second also is working now. Thank you for help!
by anonymous
And the second router ?

This rule should always be enabled. It does nothing if there is no active ipsec tunnel and is required if there us at least one.