IPSec VPN - Unable to ping remote subnets - Operation not permitted - Endian 3.0

[Guest]

[diachi]

I have two Endian boxes, trying to get an IPSec (IKEv2 on both ends) site to site (net-to-net) VPN working. The VPN connection is up and I can communicate with the directly connected subnets on both ends of the connection. However, when I try to ping any of the subnets connected to the core switch on either end I get the error "Ping: Sendmsg: Operation not permitted".

Site A:
Subnet 1 (directly connected to EFW)
10.0.3.0/24
Green IP: 10.0.3.254
Core Switch: 10.0.3.1
Subnet 2 (VLAN on core switch, routing works locally just fine)
10.0.4.0/24

Site B:
Subnet 1 (directly connected to EFW)
172.31.2.0/24
Green IP: 172.31.2.1
Core Switch: 172.31.2.2
Subnet 2 (VLAN on core switch, routing works locally just fine)
172.31.1.0/24

I can ping anything on Subnet 1 at either site from Subnet 1 at the other, for example the core switch at Site A can ping the core switch at Site B, but only on subnet 1. The endian at Site A can ping the core switch at Site B and so on.

The issue appears when I try to reach the second subnet at either site, both Endian boxes return "Ping: Sendmsg: Operation not permitted"

I've tried just turning off all firewall features at either end, but the issue remains. Does anyone have any pointers? Anything I could be missing?

Let me know if more information or any clarification is needed!

Thanks!

[Dark-Vex]

Hi! please paste the output of the command

"ipsec statusall"

Maybe there is UP only the routing for the first subnet

[diachi]

Hi! please paste the output of the command

"ipsec statusall"

Maybe there is UP only the routing for the first subnet

Here you go:

Status of IKE charon daemon (weakSwan 5.1.1, Linux 2.6.32.43-57.e51.i586, i686):
  uptime: 31 hours, since Jan 29 08:40:59 2017
  malloc: sbrk 262144, mmap 0, used 191608, free 70536
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 4
  loaded plugins: charon curl ldap aes des blowfish rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem fips-prf gmp agent xcbc cmac hmac attr kernel-netlink resolve socket-default farp stroke updown eap-identity eap-sim eap-aka eap-aka-3gpp2 eap-simaka-pseudonym eap-simaka-reauth eap-md5 eap-gtc eap-mschapv2 eap-radius xauth-generic xauth-pam dhcp lookip addrblock
Listening IP addresses:
  216...
  172.31.2.1
Connections:
     TICHome:  216......redacted.com  IKEv2, dpddelay=30s
     TICHome:   local:  [Endian1]uses pre-shared key authentication
     TICHome:   remote: [Endian2] uses pre-shared key authentication
     TICHome:   child:  172.31.2.0/24 172.31.0.0/24 172.31.1.0/24 172.31.10.0/24 === 10.0.3.0/24 10.0.4.0/24 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
     TICHome[11]: ESTABLISHED 40 minutes ago, 216...[Endian1]...216...[Endian2]
     TICHome[11]: IKEv2 SPIs: 6d8d2deb1788aa15_i* 8d04b06d0ae7bec3_r, pre-shared key reauthentication in 6 hours
     TICHome[11]: IKE proposal: AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1536
     TICHome{11}:  INSTALLED, TUNNEL, ESP SPIs: c134d717_i ca109f2c_o, IPCOMP CPIs: 23f1_i b8a3_o
     TICHome{11}:  AES_CBC_256/HMAC_MD5_96, 168 bytes_i (2 pkts, 291s ago), 168 bytes_o (2 pkts, 291s ago), rekeying in 7 hours
     TICHome{11}:   172.31.2.0/24 172.31.0.0/24 172.31.1.0/24 172.31.10.0/24 === 10.0.3.0/24 10.0.4.0/24


Let me know if you need anything else!

Thanks!!

[Dark-Vex]

Thanks for the output! I would suggest to use IKEv1 instead of IKEv2 (by default in the config there is chosen "Use both IKEv1 and IKEv2"), could you please also paste the output of "ip route show table 5"

[diachi]

Hi there, sorry for the slow reply!


I thought IKEv1 couldn't handle more than one subnet at either end of the VPN?

Output of "ip route show table 5"


10.0.4.0/24 via [redacted] dev eth1  proto static  src 172.31.2.1
10.0.3.0/24 via [redacted] dev eth1  proto static  src 172.31.2.1

[Dark-Vex]

Hi no problem 
Also with IKEv1 you can have multiple subnet they are pushed one at once instead of all in a single route, here an mine IKEv1 tunnel with multiple subnet

         G2G[372]: ESTABLISHED 3 hours ago, ...[...]......[...]
         G2G[372]: IKEv1 SPIs: 5a57aad12ddd5264_i* bf50cf14e358450a_r, pre-shared key reauthentication in 2 hours
         G2G[372]: IKE proposal: 3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1536
         G2G{1}:  INSTALLED, TUNNEL, ESP in UDP SPIs: ca5adb65_i ae0eb014_o
         G2G{1}:  3DES_CBC/HMAC_MD5_96, 1694403 bytes_i (14890 pkts, 3s ago), 168337 bytes_o (762 pkts, 3s ago), rekeying in 2 hours
         G2G{1}:   10.60.140.104/29 === 10.73.5.12/32
         G2G{1}:  INSTALLED, TUNNEL, ESP in UDP SPIs: c4675d35_i ae0eb01e_o
         G2G{1}:  3DES_CBC/HMAC_MD5_96, 614856 bytes_i (7427 pkts, 3s ago), 1376314 bytes_o (4875 pkts, 3s ago), rekeying in 2 hours
         G2G{1}:   10.60.140.104/29 === 10.168.28.169/32
         G2G{1}:  INSTALLED, TUNNEL, ESP in UDP SPIs: c0505999_i ae0eb06e_o
         G2G{1}:  3DES_CBC/HMAC_MD5_96, 621328 bytes_i (7907 pkts, 3s ago), 26025 bytes_o (210 pkts, 19s ago), rekeying in 2 hours
         G2G{1}:   10.60.140.104/29 === 10.169.63.145/32
         G2G{1}:  INSTALLED, TUNNEL, ESP in UDP SPIs: cd90db6f_i ae0eb06f_o
         G2G{1}:  3DES_CBC/HMAC_MD5_96, 1302639 bytes_i (10709 pkts, 0s ago), 3265 bytes_o (25 pkts, 0s ago), rekeying in 2 hours
         G2G{1}:   10.60.140.104/29 === 10.72.40.0/22

About your issue it seems that you have only the routing for the first subnet, the configuration it's the same on both side?
Maybe under /var/log/ipsec/ipsec.log you have some errors but anyway I would suggest to switch from IKEv2 to IKEv1

[inimennast]

I guess the question is, shouldnt the two routers be able to ping each other over the IPSec tunnel? Or only device-to-device across LANs through the tunnel?
Is there any way to confirm routing is happening as it should if my remote VPN doesnt have any devices currently connected? I can see the tunnel exists; I just cant confirm access to anything on the remote LAN.
I thought pinging router to router should pass through the tunnel, but that doesnt appear to be the case.

Thx again,